- In certain cases, a generic pointer could be assumed as a pointer to the global memory space or other spaces. With a dedicated target hook to query that address space from a given value, infer-address-space pass could infer and propagate that to all its users.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Time | Test | |
---|---|---|
380 ms | linux > HWAddressSanitizer-x86_64.TestCases::sizes.cpp |
Event Timeline
llvm/include/llvm/CodeGen/BasicTTIImpl.h | ||
---|---|---|
227 | We already have a -1 as an invalid addrspace, so optional isn't necessary | |
llvm/lib/Target/AMDGPU/AMDGPUTargetMachine.cpp | ||
533 | I would assume !isPointerTy would be unreachable | |
540 | I think this may be too aggressive and should check if it's specifically a kernel argument load. Contant address space should also not be necessary | |
llvm/lib/Transforms/Scalar/InferAddressSpaces.cpp | ||
563–571 | Won't this cast be naturally inserted with the inferred addres space? |
llvm/include/llvm/CodeGen/BasicTTIImpl.h | ||
---|---|---|
227 | OK. Do we need to document that in the IR langref? That invalid address space ID is not documented anywhere. |
llvm/lib/Target/AMDGPU/AMDGPUTargetMachine.cpp | ||
---|---|---|
540 | If the variable locates in __constant__ memory, it could only be modified on the host side. It's safe to assume any generic pointer loaded from __constant__ memory is a global one. |
llvm/lib/Transforms/Scalar/InferAddressSpaces.cpp | ||
---|---|---|
563–571 | We need to insert it explicitly as it's previously used as a generic pointer. Without this, we cannot change users of that generic pointer to a global one. |
- Add a note in the AMDGPU usage document on the assumption made here.
- Revise the test in clang.
llvm/include/llvm/CodeGen/BasicTTIImpl.h | ||
---|---|---|
227 | Shall we assume this before that reserved invalid address space ID is well-received and documented in LLVM IR ref? I will make either change in this change accordingly. |
llvm/lib/Target/AMDGPU/AMDGPUTargetMachine.cpp | ||
---|---|---|
533 | With a condition evaluation order revised, we could assert that now. |
llvm/include/llvm/CodeGen/BasicTTIImpl.h | ||
---|---|---|
227 | It's not really part of the IR. The address space is a 24-bit unsigned limit and this is already the pass convention | |
llvm/lib/Target/AMDGPU/AMDGPUTargetMachine.cpp | ||
540 | I thought we discussed the one possible case where this wasn't necessarily true | |
llvm/lib/Transforms/Scalar/InferAddressSpaces.cpp | ||
289–291 | This can be return TII->... | |
llvm/test/Transforms/InferAddressSpaces/AMDGPU/assumed-addrspace.ll | ||
13 | Should have test with load from kernel argument |
Revise the interface of that target hook.
Add a dedicated test case for value reading from parameter even though most cases are already covered in the clang test.
llvm/include/llvm/CodeGen/BasicTTIImpl.h | ||
---|---|---|
227 | You are right. Forget that totally. | |
llvm/lib/Target/AMDGPU/AMDGPUTargetMachine.cpp | ||
540 | For __constant__ memory, the language itself guarantees it won't be changed on the device side. It's very safe to assume that. The frontend should issue an error on any attempt to write it. Also, the runtime and HW is supposed to provide the facility to protect any write into that space from the device side. I thought the issue we may have the issue is the case for const variable in the global memory space and a const global pointer in the kernel argument. We need to investigate them further to identify potential risks. | |
llvm/lib/Transforms/Scalar/InferAddressSpaces.cpp | ||
289–291 | good catch. The's the result of the previous Optional<unsigned>. Now, it's revised. | |
llvm/test/Transforms/InferAddressSpaces/AMDGPU/assumed-addrspace.ll | ||
13 | most cases are already captured in the clang test. A new function is added. |
llvm/lib/Target/AMDGPU/AMDGPUTargetMachine.cpp | ||
---|---|---|
533 | Is there a suitable constant for don't know result? |
llvm/lib/Target/AMDGPU/AMDGPUTargetMachine.cpp | ||
---|---|---|
533 | I would say all generic pointers loaded from the constant memory are safe to be assumed as global ones (for AMDGPU). I explained the reason in the usage document. The constant memory could be modified by the host, where only global memory objects are visible. |
llvm/lib/Transforms/Scalar/InferAddressSpaces.cpp | ||
---|---|---|
484 | Checking this here looks strange, since it is also catching values that weren't processed as assumed address space |
llvm/lib/Transforms/Scalar/InferAddressSpaces.cpp | ||
---|---|---|
484 | It stops tracking through instructions generating pointers with assumed AS. It's not necessary to check their operands as the result is assumed. For instructions without assumed AS results, we need to track them through their operands. |
We already have a -1 as an invalid addrspace, so optional isn't necessary