OpenMP TR8 present map type modifier issues

Hi,

In the 7/29 OpenMP in LLVM call, we discussed several issues related to OpenMP TR8’s present map type modifier. As suggested, I’ve discussed these issues with James Beyer. Below are the conclusions I gathered from that discussion and my plans going forward. Please let me know if there are any concerns.

Complaint for data that’s not present on exit from target data region

OpenMP TR8 sec. 2.22.7.1 “map Clause”, p. 321, L23-26 states:

If the map clause appears on a target, target data, target enter
data or target exit data construct with a present map-type-modifier
then on entry to the region if the corresponding list item does not
appear in the device data environment an error occurs and the
program terminates.

There is no corresponding statement about the exit from a region. As a result, the following test case is a valid OpenMP program that should not fail:

#pragma omp target enter data map(alloc:i)
#pragma omp target data map(present, alloc: i)
{
#pragma omp target exit data map(delete:i)

} // i isn’t present, but the present check doesn’t happen on exit

James agrees that this is the intended interpretation of TR8.

My plan is to immediately push D84422, which implements this behavior and includes the above test.

Complaint for data that’s not present on exit from target region

James agrees the above interpretation also applies to target regions. However, I have not formulated a valid test case. For example, James agrees the following attempt isn’t valid OpenMP because it has a race and might pass or fail:

#pragma omp target enter data map(alloc:i)

#pragma omp target nowait map(present, alloc:i)

// i might not be present here, so the entry present check might fail

{}

#pragma omp target exit data map(delete:i)

D84422 includes a comment saying we’re not bothering to eliminate the presence check on exit from a target region because we lack a test case.

My plan is not to pursue this issue for now. If someone later manages to write a test, I’d be happy to fix the implementation in a followup patch.

Effective ordering of map clauses

OpenMP TR8 sec. 2.22.7.1 “map Clause”, p. 319, L10-11 states:

For a given construct, the effect of a map clause with the to, from,
or tofrom map-type is ordered before the effect of a map clause with
the alloc, release, or delete map-type.

However, L14-16 states:

If a map clause with a present map-type-modifier is present in a map
clause, then the effect of the clause is ordered before all other
map clauses that do not have the present modifier.

James agrees this combination is contradictory for cases like map(tofrom:var) map(present,alloc:var). He says it was intended that the reordering in L10-11 be applied first, and then the reordering in L14-16 be applied. We also discussed with Tobias Burnus from Mentor, who then filed OpenMP spec issue 2337, which also covers additional issues with the way reordering is specified.

My plan for this issue is to add the following entries to Clang’s OpenMP status doc:

For 5.0, in which L10-11 also appear but do not seem to be implemented in Clang:


> device extension | map clause reordering based on map types | :none:`unclaimed` | |

For 5.1:

> device extension | map clause reordering reordering based on 'present' modifier | :none:`unclaimed` | |

Thanks.

Joel

says it was intended that the reordering in L10-11 be applied first, and then the reordering in L14-16 be applied.

We probably need to discuss this in OpenMP Accel meeting, if you apply the above rule then present becomes a no-op.

Ravi

Hi Ravi,

says it was intended that the reordering in L10-11 be applied first, and then the reordering in L14-16 be applied.

We probably need to discuss this in OpenMP Accel meeting, if you apply the above rule then present becomes a no-op.

No, the present reordering rule is applied last, guaranteeing that map clauses with the present modifier are sorted first.

Joel

Ok. Then I misunderstood the statement.