PrivateArgumentManager shall immediately allocate firstprivates if they
are bases for the next parameters and the next paramaters rely on the
fact that the base musst be allocated already.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
openmp/libomptarget/src/omptarget.cpp | ||
---|---|---|
1068 | I have a quick question: Does front end order all arguments? For example, let's say a user write the following code: #pragma omp target first private(a.p1[0:N], b, a.p2[0:N], c, a.p3[0:N]) where p1, p2 and p3 are members of a struct a. Then when passing to the runtime library, Args[I], Args[I+1] and Args[I+2] should be corresponding to a.p1[0:N], a.p2[0:N], a.p3[0:N], right? They'll not be interleaved by b and c. | |
openmp/libomptarget/test/mapping/lambda_mapping.cpp | ||
10 | Really interesting fix. I didn't realize that lambda function is captured as a first-private argument. |
openmp/libomptarget/src/omptarget.cpp | ||
---|---|---|
1068 | The order is important for correct passing of captured variables to the target regions (order of the arguments for the outlined target functions). For target regions it is not always defined by the order in the mappping/data-sharing clauses, but the order of captured variables, which can be different. | |
openmp/libomptarget/test/mapping/lambda_mapping.cpp | ||
10 | In future we may try to implement the deepcopy of the record with data members having reference data types in the similar way. |
openmp/libomptarget/src/omptarget.cpp | ||
---|---|---|
1068 | I see. Thanks for the explanation. |
depend on