- Add DeviceTy::data_alloc, DeviceTy::data_delete, DeviceTy::data_alloc, DeviceTy::synchronize pass-through functions. Avoid directly accessing Device.RTL
- Fix the type of the first argument of synchronize_ty in rth.h, device id is int32_t which is consistent with other functions.
Details
Diff Detail
Event Timeline
Thx for the cleanup, minor comments below.
openmp/libomptarget/src/device.cpp | ||
---|---|---|
357 | I guess the HostPtr is never used by any RTL? | |
362 | No function comments here then. | |
441 | same as above. | |
openmp/libomptarget/src/device.h | ||
197 | While we are at it, comments for both, full sentences, explain the result of delete. | |
221 | Same as above. |
openmp/libomptarget/src/device.cpp | ||
---|---|---|
362 | https://llvm.org/docs/CodingStandards.html#doxygen-use-in-documentation-comments |
openmp/libomptarget/src/device.h | ||
---|---|---|
198 | Although HstPtr is not used here, it is still part of the plugin interface. In order to be compatible with the plugin interface, I think either HstPtr is kept here, or remove the HstPtr from the plugin interface. |
openmp/libomptarget/src/device.h | ||
---|---|---|
198 | My intention is to remove it fully. Due to compatibility consideration, it has not been removed in the plugin interface. I insist in not exposing HstPtr here. |
openmp/libomptarget/src/device.h | ||
---|---|---|
198 | I think it doesn't make any sense. The so-called compatibility is, we may use it somewhere or sometime, especially in the future. If the plugin interface leaves it, considering maybe in the future we may use it to assist the allocation of device memory, or something else, then there is no reason to remove it from data_alloc because data_alloc is also an interface. |
openmp/libomptarget/src/device.h | ||
---|---|---|
198 | Here I'm not intended to change __tgt_rtl_data_alloc in omptargetplugin.h. Any changes there requires a different discussion. |
openmp/libomptarget/src/device.h | ||
---|---|---|
198 | I know. But data_alloc calls __tgt_rtl_data_alloc and it does have an argument for host pointer, right? Your intention is to take data_alloc as the only user of __tgt_rtl_data_alloc, and hope others to use data_alloc to allocate device memory in the future instead of using the function pointer directly. If __tgt_rtl_data_alloc has an argument for host pointer, why does data_alloc not have the argument? |
openmp/libomptarget/src/device.h | ||
---|---|---|
198 | Maybe my initial thoughts were not accurate. As long as __tgt_rtl_data_alloc interface stays as it is now. DeviceTy::data_alloc cannot fully cover it. Any codes which are not visible to us (downstream compilers) can still used them directly just like any other __tgt_rtl functions. So far all the calls to __tgt_rtl_data_alloc in libomptarget.so are only intended for allocating device memory and HstBegin mapping to TgtBegin is done outside __tgt_rtl_data_alloc call. My intention of only using DeviceTy::data_alloc is not because of its covering all the __tgt_rtl_data_alloc feature but the real use we have seen so far only needs DeviceTy::data_alloc. |
openmp/libomptarget/src/device.h | ||
---|---|---|
198 | Given that case, if you really don't want to pass a nullptr to it when using data_alloc, it would be better to define data_alloc as any of following:
But I think the first one is less confusing since we only have one plugin interface and it does not have such distinction. |
openmp/libomptarget/src/device.h | ||
---|---|---|
198 | I will adopt 1. |
openmp/libomptarget/src/device.h | ||
---|---|---|
198 | Yes, it is, but just in one case for now. :-) |
openmp/libomptarget/src/device.h | ||
---|---|---|
198 | Done with adopting 1. |
openmp/libomptarget/src/omptarget.cpp | ||
---|---|---|
848 | Please also add HstPtrBegin here. |
openmp/libomptarget/src/omptarget.cpp | ||
---|---|---|
848 | done |
While we are at it, comments for both, full sentences, explain the result of delete.