| Issue |
179973
|
| Summary |
[SPIRV] llvm.used and related variables not properly handled
|
| Labels |
bug,
backend:SPIR-V
|
| Assignees |
|
| Reporter |
sarnex
|
Previously, there was no special handling for variables like `llvm.used` in the SPIR-V backend, so the backend would just try to emit them as normal variables.
This caused many problems, one common example is the constant initializer for the variables would contain IR that illegal and cannot be legalized (ex. addrspacecast from `UniformConstant` to `Generic`), so the backend would blow up saying these instructions are illegal.
So, changes were made to skip emission of these variables and any types defined by them, see the PRs at the bottom of this bug report.
However, if we take a step back, it's not totally clear what these variables should do in SPIR-V.
For example, the `llvm.used` definition is `If a symbol appears in the @llvm.used list, then the compiler, assembler, and linker are required to treat the symbol as if there is a reference to the symbol that it cannot see (which is why they have to be named).`, but it's unclear what `compiler`, `assembler` and `linker` mean in this context ([reference](https://github.com/llvm/llvm-project/pull/179498#issuecomment-3848264168))
In addition, out-of-tree tools are required to use SPIR-V with Clang, such as `spirv-as` and `spirv-link`, and these tools seem to optimize out unreferenced variables today.
We need to:
1) Define what `llvm.used` and related variables should do in `SPIR-V`
2) Determine what impact the results of 1) have on the SPIR-V backend as well as out-of-tree tools such as those in SPIRV-Tools
3) Possibly define a new SPIR-V extension
4) Implement any changes to the relevant software projects
See the below PRs for context:
https://github.com/llvm/llvm-project/pull/162678
https://github.com/llvm/llvm-project/pull/179498
_______________________________________________
llvm-bugs mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs