Add asm register information for SPIR-V #78950
Conversation
|
(rust_highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
When LLVM adds a SPIR-V target, it will become reachable using a custom target. Before that it will likely already error when trying to start codegen. |
compiler/rustc_target/src/asm/mod.rs
Outdated
| @@ -177,6 +179,7 @@ pub enum InlineAsmArch { | |||
| Hexagon, | |||
| Mips, | |||
| Mips64, | |||
| Spirv, | |||
There was a problem hiding this comment.
Small nit: this should be SpirV.
There was a problem hiding this comment.
The formal capitalization is SPIR-V, all caps, so just checking, should it be SPIRV or SpirV? Looks like RISC-V is also all caps and that's spelled RiscV here, so yeah, SpirV?
|
r? @Amanieu |
This matches the capitalization of RiscV
I think @bors r+ |
|
📌 Commit 0e34b73 has been approved by |
bors
added
S-waiting-on-bors
Add asm register information for SPIR-V As discussed in [zulip](https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/Defining.20asm!.20for.20new.20architecture), we at [rust-gpu](https://github.com/EmbarkStudios/rust-gpu) would like to support `asm!` for our SPIR-V backend. However, we cannot do so purely without frontend support: [this match](https://github.com/rust-lang/rust/blob/d4ea0b3e46a0303d5802b632e88ba1ba84d9d16f/compiler/rustc_target/src/asm/mod.rs#L185) fails and so `asm!` is not supported ([error reported here](https://github.com/rust-lang/rust/blob/d4ea0b3e46a0303d5802b632e88ba1ba84d9d16f/compiler/rustc_ast_lowering/src/expr.rs#L1095)). To resolve this, we need to stub out register information for SPIR-V to support getting the `asm!` content all the way to [`AsmBuilderMethods::codegen_inline_asm`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/traits/trait.AsmBuilderMethods.html#tymethod.codegen_inline_asm), at which point the rust-gpu backend can do all the parsing and codegen that is needed. This is a pretty weird PR - adding support for a backend that isn't in-tree feels pretty gross to me, but I don't see an easy way around this. `@Amanieu` said I should submit it anyway, so, here we are! Let me know if this needs to go through a more formal process (MCP?) and what I should do to help this along. I based this off the [wasm asm PR](rust-lang#78684), which unfortunately this PR conflicts with that one quite a bit, sorry for any merge conflict pain :( --- Some open questions: - What do we call the register class? Some context, SPIR-V is an SSA-based IR, there are "instructions" that create IDs (referred to as `<id>` in the spec), which can be referenced by other instructions. So, `reg` isn't exactly accurate, they're SSA IDs, not re-assignable registers. - What happens when a SPIR-V register gets to the LLVM backend? Right now it's a `bug!`, but should that be a `sess.fatal()`? I'm not sure if it's even possible to reach that point, maybe there's a check that prevents the `spirv` target from even reaching that codepath.
Rollup of 7 pull requests Successful merges: - rust-lang#76730 (Fix rustdoc rendering of by-value mutable arguments in async fn) - rust-lang#78836 (Implement destructuring assignment for structs and slices) - rust-lang#78857 (Improve BinaryHeap performance) - rust-lang#78950 (Add asm register information for SPIR-V) - rust-lang#78970 (update rustfmt to v1.4.25) - rust-lang#78972 (Update cargo) - rust-lang#78987 (extend min_const_generics param ty tests) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
As discussed in zulip, we at rust-gpu would like to support
asm!for our SPIR-V backend. However, we cannot do so purely without frontend support: this match fails and soasm!is not supported (error reported here). To resolve this, we need to stub out register information for SPIR-V to support getting theasm!content all the way toAsmBuilderMethods::codegen_inline_asm, at which point the rust-gpu backend can do all the parsing and codegen that is needed.This is a pretty weird PR - adding support for a backend that isn't in-tree feels pretty gross to me, but I don't see an easy way around this. @Amanieu said I should submit it anyway, so, here we are! Let me know if this needs to go through a more formal process (MCP?) and what I should do to help this along.
I based this off the wasm asm PR, which unfortunately this PR conflicts with that one quite a bit, sorry for any merge conflict pain :(
Some open questions:
<id>in the spec), which can be referenced by other instructions. So,regisn't exactly accurate, they're SSA IDs, not re-assignable registers.bug!, but should that be asess.fatal()? I'm not sure if it's even possible to reach that point, maybe there's a check that prevents thespirvtarget from even reaching that codepath.