Added options -f-[no]openmp-cuda-const-firstprivate to control the
address space of the the corresponding global variable, created for the
target firstprivate variable. Disabled by default.
Details
- Reviewers
jdoerfert
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Event Timeline
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.
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.
Because you mentioned that it would not work if we would like to use const_cast to remove constness. It should be faster than the global memory, that's why I introduced this feature.
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.
Ye, but it will require some rework in the libomptarget and the compiler itself. Instead, I just reused the existing mechanism to allocate the memory in the constant pool and use it instead of the global.