[Openmp-dev] OpenMP TR8 present map type modifier issues

[Joel E. Denny via Openmp-dev]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/openmp-dev/attachments/20200804/3dfc63c0/attachment.html>