================
@@ -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 %}
+
+@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
----------------
s-perron wrote:
Where does this `addrsspacecast` come from? I would have expected the operand
on the load to be `ptr addrspace(10) %p`.
I wonder because in SPIR-V the storage class matters. We cannot mix and match
pointer from different storage classes. If we allow/generate address space
casts generally, we could end up with problems.
In DXC, we were a little loose with storage classes in very specific
situations, and we could do that because he have a pass in spirv-opt that will
fix up those very specific situations.
https://github.com/llvm/llvm-project/pull/116636
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
