[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