[PATCH] D99689: [OPENMP]Add option -fopenmp-cuda-const-firstprivate to control address space of the corresponding global.
Johannes Doerfert via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Wed Mar 31 20:16:10 PDT 2021
jdoerfert added a comment.
In D99689#2662860 <https://reviews.llvm.org/D99689#2662860>, @ABataev wrote:
> In D99689#2662856 <https://reviews.llvm.org/D99689#2662856>, @jdoerfert wrote:
>
>> In D99689#2662852 <https://reviews.llvm.org/D99689#2662852>, @ABataev wrote:
>>
>>> In D99689#2662848 <https://reviews.llvm.org/D99689#2662848>, @jdoerfert wrote:
>>>
>>>> Can you please show me a test case or explain to me when/how this global is actually used.
>>>
>>> It is passed as an argument to the target region. When libomptarget requests the memory for the firstprivate, it returns the pointer to this const global, which then passed as argument to the kernel.
>>
>> So if we use it, why would we disable it?
>
> With this new option you can control how to handle it. You can either dynamically allocate memory using libomptarget memmanager (default for this option) or use preallocated constant memory, if you're not going to remove the var constantness.
I get what the new option does, what I want to know is why we would ever want to disable the constant memory usage. Is it potentially slower or otherwise problematic?
Also, I am not sure but I imagine the generated code would be better if we would use the constant global directly, or, add the address space to the corresponding kernel argument.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D99689/new/
https://reviews.llvm.org/D99689
More information about the cfe-commits
mailing list