[clang] [llvm] [SPIR-V] Fixup storage class for global private (PR #116636)
Nathan Gauër via cfe-commits
cfe-commits at lists.llvm.org
Fri Nov 29 08:48:33 PST 2024
================
@@ -0,0 +1,17 @@
+; RUN: llc -verify-machineinstrs -O0 -mtriple=spirv64-unknown-unknown %s -o - | FileCheck %s
+; RUN: %if spirv-tools %{ llc -O0 -mtriple=spirv64-unknown-unknown %s -o - -filetype=obj | spirv-val %}
+
+ at PrivInternal = internal addrspace(10) global i32 456
+; CHECK-DAG: %[[#type:]] = OpTypeInt 32 0
+; CHECK-DAG: %[[#ptrty:]] = OpTypePointer Private %[[#type]]
+; CHECK-DAG: %[[#value:]] = OpConstant %[[#type]] 456
+; CHECK-DAG: %[[#var:]] = OpVariable %[[#ptrty]] Private %[[#value]]
+
+define spir_kernel void @Foo() {
+ %p = addrspacecast ptr addrspace(10) @PrivInternal to ptr
----------------
Keenuts wrote:
This test is specifically to validate we can lower an addrspacecast from private to function.
This pattern can be generated by the actual codegen:
- https://clang.llvm.org/doxygen/CodeGenModule_8cpp_source.html#l05259
- https://clang.llvm.org/doxygen/CodeGenModule_8cpp_source.html#l04982
What happens is a global is recreated with the correct AS, and where a load was done (or function call with this as parameter), the `addrspacecast` is added.
In basic cases, I don't think this is an issue, as it generates a `load(addrspacecast(ptr))`.
BUT I suspect if we start to have references, then it could become an issue, as the ptr will be changed to another AS, and suddenly the `OpTypePtr` becomes `Function` instead of `Private`?
https://github.com/llvm/llvm-project/pull/116636
More information about the cfe-commits
mailing list