- If a generic pointer is loaded from a readonly and noalias kernel pointer argument, it could be assumed as a global one. + readonly prevents the possible modifications from the device side, and + noalias ensures that pointer won't alias to any other objects in the whole kernel execution lifetime. + Taking them together, it's safe to assume that memory object could only be modified on the host side and contains global pointers only.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/lib/Target/AMDGPU/AMDGPUTargetMachine.cpp | ||
---|---|---|
553 | Readonly is incorrect here, as it only indicates the function does not write to the memory and does not indicate the memory may be changed by another function/thread. I also don't think noalias is really the correct check for the owned object |
llvm/lib/Target/AMDGPU/AMDGPUTargetMachine.cpp | ||
---|---|---|
553 | That readonly atttribute is marked in function attribute deduction pass by checking every use of a pointer argument, including if it's passed into another sub-func. It's only marked as readonly when it's safe. It's safe to assume there's no write though a pointer argument marked with readonly. |
llvm/lib/Target/AMDGPU/AMDGPUTargetMachine.cpp | ||
---|---|---|
553 | Yes, it infers that *this* function did not modify the memory. It's a step further to conclude that no function exists that's modifying the memory. A different kernel could have access to the same memory which it is writing to |
the case is no longer valid considering concurrent kernel execution.
llvm/lib/Target/AMDGPU/AMDGPUTargetMachine.cpp | ||
---|---|---|
553 | yeah, by allowing concurrent kernel execution, the assumption is no longer held. |
Readonly is incorrect here, as it only indicates the function does not write to the memory and does not indicate the memory may be changed by another function/thread. I also don't think noalias is really the correct check for the owned object