This is an archive of the discontinued LLVM Phabricator instance.

[OPENMP]Add option -fopenmp-cuda-const-firstprivate to control address space of the corresponding global.
Needs ReviewPublic

Authored by ABataev on Mar 31 2021, 2:30 PM.

Details

Reviewers
jdoerfert
Summary

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.

Diff Detail

Event Timeline

ABataev created this revision.Mar 31 2021, 2:30 PM
ABataev requested review of this revision.Mar 31 2021, 2:30 PM
Herald added a project: Restricted Project. · View Herald TranscriptMar 31 2021, 2:30 PM
Herald added a subscriber: sstefan1. · View Herald Transcript

Can you please show me a test case or explain to me when/how this global is actually used.

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.

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?

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.

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.

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?

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.

ABataev updated this revision to Diff 338100.Apr 16 2021, 7:05 AM

Rebase + update