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

[Joel E. Denny via Openmp-dev]

Hi Ravi,

On Tue, Aug 4, 2020 at 2:49 PM Narayanaswamy, Ravi <
ravi.narayanaswamy at intel.com> wrote:

> 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



>
>
> Ravi
>
>
>
> *From:* Openmp-dev <openmp-dev-bounces at lists.llvm.org> * On Behalf Of *Joel
> E. Denny via Openmp-dev
> *Sent:* Tuesday, August 04, 2020 11:37 AM
> *To:* Openmp-dev <openmp-dev at lists.llvm.org>
> *Cc:* James Beyer <jbeyer at nvidia.com>; Tobias Burnus <
> tobias_burnus at mentor.com>
> *Subject:* [Openmp-dev] 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/openmp-dev/attachments/20200804/4a2e5dba/attachment.html>