[Openmp-commits] [PATCH] D60223: [OpenMP][libomptarget] Add support for target link variables when unified memory is enabled
Alexandre Eichenberger via Phabricator via Openmp-commits
openmp-commits at lists.llvm.org
Wed Apr 3 12:23:37 PDT 2019
AlexEichenberger requested changes to this revision.
AlexEichenberger marked 2 inline comments as done.
AlexEichenberger added a comment.
This revision now requires changes to proceed.
see comments
================
Comment at: libomptarget/include/omptarget.h:51
+ /// Target link
+ OMP_TGT_MAPTYPE_USE_HOST_VAR = 0x400,
// member of struct, member given by [16 MSBs] - 1
----------------
ABataev wrote:
> Do you really need this flag? Can you use something different? For example, `OMP_TGT_MAPTYPE_LITERAL` or `OMP_TGT_MAPTYPE_PRIVATE`?
I don't believe it is needed, as all is handled while registering the device library. If anything, you could just use the literal to naturally move the host pointer address to the device. This is if you want to avoid going through the indirection already set in place for globals mapped with "link" clause
================
Comment at: libomptarget/plugins/cuda/src/rtl.cpp:443
+ // be overwritten.
+ cuMemcpyHtoD(cuptr, e->addr, 8);
+ DP("Copy linked variable host address (" DPxMOD ")"
----------------
ABataev wrote:
> `8`->`sizeof(void*)`
Shouldn't this code be guarded by some "if the runtime is in unified memory mode," and if we see TARGET_LINK and the runtime is not in unified memory mode, should't there be some error as things are likely to go seriously wrong?
================
Comment at: libomptarget/src/rtl.cpp:180
}
-
- if (entry->flags & OMP_DECLARE_TARGET_LINK) {
----------------
Same comment here... if the runtime is in non-unified memory mode, should't it be an error to see a link?
Repository:
rOMP OpenMP
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D60223/new/
https://reviews.llvm.org/D60223
More information about the Openmp-commits
mailing list