================
@@ -0,0 +1,63 @@
+; RUN: llc -mtriple=spirv-unknown-vulkan1.3-vertex -o - %s | FileCheck %s
+; RUN: %if spirv-tools %{ llc -mtriple=spirv-unknown-vulkan1.3-vertex \
+; RUN: -filetype=obj -o - %s | spirv-val --target-env vulkan1.3 %}
+;
+; Confirm that an addrspace(7) global protected by llvm.compiler.used appears
+; in the SPIR-V output as a distinct OpVariable, even though it has no IR
+; users, and that it is also listed in the OpEntryPoint interface.
+;
+; @used_input has a real load. @dead_input is only in llvm.compiler.used.
+;
+; %[[#USED]] and %[[#DEAD]] capture different IDs (Location 0 vs 1), so the
+; OpVariable checks below require two distinct OpVariable Input instructions.
+;
+; Without the processGlobalValue fix in SPIRVEmitIntrinsics.cpp, @dead_input
+; gets no spv_unref_global, buildGlobalVariable is never called for it, and
+; both OpDecorate Location 1 and the second OpVariable Input are absent.
----------------
jmmartinez wrote:
I think this comment will read weirdly after the fix lands (or if anyone ever
changes the file/function names).
Can I suggest adding a test for this intermediate invisible state to make it
visible?
We can add a test with a `--stop-after=<the-pass>` and check on the LLVM-IR. We
can check that we actually emit a `spv_unref_global` for them.
---
I think this could be a problem for other variables, right?
ATM, we have a test `global-var-no-functions.ll` with a single variable:
```llvm
@global_var = addrspace(1) global i32 zeroinitializer
```
What if that variable had no initializer?
I think the backend should still emit the variable (regardless of if it is or
not in any of `llvm.compiler.used`). and not be doing some
dead-code-elimination.
https://github.com/llvm/llvm-project/pull/196404
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
