Page MenuHomePhabricator

[LIBOMPTARGET]Do not try to optimize bases for the next parameters.

Authored by ABataev on Aug 28 2020, 5:57 AM.



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.

Diff Detail

Event Timeline

ABataev created this revision.Aug 28 2020, 5:57 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 28 2020, 5:57 AM
ABataev requested review of this revision.Aug 28 2020, 5:57 AM
grokos accepted this revision.Aug 28 2020, 7:12 AM

Looks good!


depend on

This revision is now accepted and ready to land.Aug 28 2020, 7:12 AM
tianshilei1992 added inline comments.

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.


Really interesting fix. I didn't realize that lambda function is captured as a first-private argument.

ABataev added inline comments.Aug 29 2020, 6:13 PM

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.
Yes, frontend already reorders maps to gather elements with the same bases. It is required for correct memory allocation of the partially copied structures.


In future we may try to implement the deepcopy of the record with data members having reference data types in the similar way.

tianshilei1992 added inline comments.Aug 29 2020, 6:24 PM

I see. Thanks for the explanation.