[Openmp-commits] [PATCH] D107925: [OpenMP] Use IsHostPtr where needed for targetDataEnd
Joel E. Denny via Phabricator via Openmp-commits
openmp-commits at lists.llvm.org
Wed Aug 11 13:01:26 PDT 2021
jdenny created this revision.
jdenny added reviewers: grokos, tianshilei1992, RaviNarayanaswamy, jdoerfert.
jdenny added a project: OpenMP.
Herald added subscribers: guansong, yaxunl.
jdenny requested review of this revision.
Herald added a subscriber: sstefan1.
As discussed in D105990 <https://reviews.llvm.org/D105990>, without this patch, `targetDataEnd`
determines whether to transfer data or delete a device mapping (as
opposed to assuming it's in shared memory) using two different
conditions, each of which are broken for some cases:
1. `!(UNIFIED_SHARED_MEMORY && TgtPtrBegin == HstPtrBegin)`: The broken case is rare: the device and host might happen to use the same address for their mapped allocations. I don't know how to write a test that's likely to reveal this case, but this patch does fix it, as discussed below.
2. `!UNIFIED_SHARED_MEMORY || HasCloseModifier`: There are at least two broken cases:
1. The `close` modifier might have been specified on an `omp target enter data` but not the corresponding `omp target exit data`, which thus might falsely assume a mapping is in shared memory. The test `unified_shared_memory/close_enter_exit.c` already has a missing deletion as a result, and this patch adds a check for that. This patch also adds the new test `close_member.c` to reveal a missing transfer and deletion.
2. Use of discrete memory might have been forced by `omp_target_associate_ptr`, as in the test `unified_shared_memory/api.c`. In the current `targetDataEnd` implementation, this condition turns out not be used for this case: because the reference count is infinite, a transfer is possible only with an `always` modifier, and this condition is never used in that case. To ensure it's never used for that case in the future, this patch adds the test `unified_shared_memory/associate_ptr.c`.
Fortunately, `DeviceTy::getTgtPtrBegin` already has a solution: it
reports whether the allocation was found in shared memory via the
variable `IsHostPtr`.
After this patch, `HasCloseModifier` is no longer used in
`targetDataEnd`, and I wonder if the `close` modifier is ever useful
on an `omp target data end`.
Repository:
rG LLVM Github Monorepo
https://reviews.llvm.org/D107925
Files:
openmp/libomptarget/src/device.cpp
openmp/libomptarget/src/device.h
openmp/libomptarget/src/omptarget.cpp
openmp/libomptarget/test/unified_shared_memory/associate_ptr.c
openmp/libomptarget/test/unified_shared_memory/close_enter_exit.c
openmp/libomptarget/test/unified_shared_memory/close_member.c
-------------- next part --------------
A non-text attachment was scrubbed...
Name: D107925.365828.patch
Type: text/x-patch
Size: 8120 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/openmp-commits/attachments/20210811/123d522d/attachment.bin>
More information about the Openmp-commits
mailing list