[OMPT] ompt_callback_target_data_op_emi does not pass allocated pointer in callback
#64671
Comments
|
@llvm/issue-subscribers-openmp |
|
Hey and thanks for bringing this to our attention! So, from my perspective this issue is only affecting the reported target pointer for the DataOp I don't completely follow where the NVHPC is surpassing the amount of provided information in that case. Other than that I'm able to reproduce and also fix the issue. So, this will only have an effect on DataOp EMI callbacks where Thanks for taking the time esp. to provide an elaborate issue description -- much appreciated! |
Yes, you're right. This only affects
To be honest, I misread the output of NVHPC. There's no difference. Sorry for the confusion.
That looks perfect! With this, we should be able to use the same code in Score-P we've been using until now. |
No worries, I just wanted to make sure I understood the situation.
That's great to hear! I have another question, since I'm thinking about adapting the corresponding OMPT (EMI) testcases: |
Looking at the OpenMP specifications, we should see the data address after the operation has finished. In this case, it would be the allocation of data. The specification allows data aggregation to reduce the number of callbacks though, which means that we may see less The only case where I wouldn't expect a pointer to be returned in the callback is when the allocation fails for some reason (for example insufficient memory). Maybe there's another case I haven't thought of. |
|
Thanks for the quick response! With that info, I guess I'll check that there are no null values: |
|
Phabricator review is up: @Thyre I took the liberty to directly subscribe you to the review :) |
This patch fixes: llvm/llvm-project#64671 DataOp EMI callbacks would not report the correct target pointer. This is now alleviated by passing a `void**` into the function which emits the actual callback, then evaluating that pointer. Note: Since this is only done after the pointer has been properly updated, only `endpoint=2` callbacks will show a non-null value. Reviewed By: dhruvachak, jdoerfert Differential Revision: https://reviews.llvm.org/D157996 (cherry picked from commit 41f3626)
This patch fixes: llvm/llvm-project#64671 DataOp EMI callbacks would not report the correct target pointer. This is now alleviated by passing a `void**` into the function which emits the actual callback, then evaluating that pointer. Note: Since this is only done after the pointer has been properly updated, only `endpoint=2` callbacks will show a non-null value. Reviewed By: dhruvachak, jdoerfert Differential Revision: https://reviews.llvm.org/D157996 (cherry picked from commit 41f3626)
This patch fixes: llvm#64671 DataOp EMI callbacks would not report the correct target pointer. This is now alleviated by passing a `void**` into the function which emits the actual callback, then evaluating that pointer. Note: Since this is only done after the pointer has been properly updated, only `endpoint=2` callbacks will show a non-null value. Reviewed By: dhruvachak, jdoerfert Differential Revision: https://reviews.llvm.org/D157996
This patch fixes: llvm#64671 DataOp EMI callbacks would not report the correct target pointer. This is now alleviated by passing a `void**` into the function which emits the actual callback, then evaluating that pointer. Note: Since this is only done after the pointer has been properly updated, only `endpoint=2` callbacks will show a non-null value. Reviewed By: dhruvachak, jdoerfert Differential Revision: https://reviews.llvm.org/D157996
This patch fixes: llvm#64671 DataOp EMI callbacks would not report the correct target pointer. This is now alleviated by passing a `void**` into the function which emits the actual callback, then evaluating that pointer. Note: Since this is only done after the pointer has been properly updated, only `endpoint=2` callbacks will show a non-null value. Reviewed By: dhruvachak, jdoerfert Differential Revision: https://reviews.llvm.org/D157996
This patch fixes: llvm#64671 DataOp EMI callbacks would not report the correct target pointer. This is now alleviated by passing a `void**` into the function which emits the actual callback, then evaluating that pointer. Note: Since this is only done after the pointer has been properly updated, only `endpoint=2` callbacks will show a non-null value. Reviewed By: dhruvachak, jdoerfert Differential Revision: https://reviews.llvm.org/D157996
This patch fixes: llvm#64671 DataOp EMI callbacks would not report the correct target pointer. This is now alleviated by passing a `void**` into the function which emits the actual callback, then evaluating that pointer. Note: Since this is only done after the pointer has been properly updated, only `endpoint=2` callbacks will show a non-null value. Reviewed By: dhruvachak, jdoerfert Differential Revision: https://reviews.llvm.org/D157996
This patch fixes: llvm#64671 DataOp EMI callbacks would not report the correct target pointer. This is now alleviated by passing a `void**` into the function which emits the actual callback, then evaluating that pointer. Note: Since this is only done after the pointer has been properly updated, only `endpoint=2` callbacks will show a non-null value. Reviewed By: dhruvachak, jdoerfert Differential Revision: https://reviews.llvm.org/D157996
This patch fixes: llvm#64671 DataOp EMI callbacks would not report the correct target pointer. This is now alleviated by passing a `void**` into the function which emits the actual callback, then evaluating that pointer. Note: Since this is only done after the pointer has been properly updated, only `endpoint=2` callbacks will show a non-null value. Reviewed By: dhruvachak, jdoerfert Differential Revision: https://reviews.llvm.org/D157996
Description
Recently, LLVM has added parts of the target callbacks of the OMPT interface. During tests, I found a regression compared to the implementation previously found in ROCm and aomp.
The callback
ompt_callback_target_data_opis called when memory is allocated on a selected target device.The
optypematchesompt_target_data_alloc. We get the number of bytes allocated, but do not receive the allocated pointer both duringompt_scope_beginorompt_scope_endin the_emicallbacks. Instead, both pointers have a value of 0 when usingomp_target_alloc. When using#pragma omp target enter data map([...])the fieldsrc_addris set to the host pointer, but we still do not get the device pointer. The pointer is correctly set on data operations and during the delete operation.It's worth noting that the OpenMP specifications do not specifically state that those pointers need to be passed to the callbacks.
However, without those pointers, tools have a hard time tracking memory allocations correctly, only knowing the amount of memory.
Other runtimes (NVHPC, ROCm) solve this issue by passing the allocated pointer during
ompt_target_data_allocwithendpoint = ompt_scope_endNote: The callback
ompt_callback_target_data_opalso doesn't pass the pointer to the tools interface. However, since the callback is dispatched before the actual allocation I wouldn't necessarily consider this as an issue. ROCm and aomp have dispatched the callbacks the same way. Only NVHPC somehow knows the allocated pointer already and passes it in both cases.Reproducer
The following code can be used to reproduce the issue. The OMPT interface was mostly copied from an aomp smoke test with small changes to prevent the tool to abort on
omp_target_alloc.Running the tool with Clang, we see the following output:
Notice that the field
deststays(nil)for the whole allocation process. This isn't the case with other runtimes:ROCm 5.6:
aomp 17.0-3:
Both ROCm and aomp are do not dispatch
ompt_callback_targetfor#pragma omp target [enter|exit] datacorrectly, but the data operations contain the pointer during allocation.NVHPC 23.7:
The passed pointers in NVHPC look a bit weird, but in general, pointers are passed to the callbacks.
The text was updated successfully, but these errors were encountered: