rustc_target: don't limit SPIR-V inline asm! types to a fixed subset. #79171
Conversation
|
Also, regarding #78950 (comment), it might be a good idea to switch from |
a3b4474 to
1a6a667
Compare
| @@ -473,6 +471,17 @@ impl fmt::Display for InlineAsmRegOrRegClass { | |||
| } | |||
| } | |||
|
|
|||
| /// Type constrains for a particular register class. | |||
There was a problem hiding this comment.
| /// Type constrains for a particular register class. | |
| /// Type constraints for a particular register class. |
| /// Type constrains for a particular register class. | ||
| #[derive(Copy, Clone, Debug, Eq, PartialEq)] | ||
| pub enum InlineAsmSupportedTypes { | ||
| /// Any type is allowed. |
There was a problem hiding this comment.
Not exactly: this is still limited to primitive types and SIMD vectors.
By the way, is SPIR-V able to handle more exotic types such as i128?
There was a problem hiding this comment.
By the way, is SPIR-V able to handle more exotic types such as
i128?
For a general background: theoretically yes, integers are declared using an arbitrary bit width (like llvm), and the spec doesn't disallow (or even mention) 128 bit integers. Practically no, though, considering that there are extensions to enable support for 8 bit, 16 bit, and 64 bit integers, which implies no support for 128 bit considering there's no extension for it (the SPIR-V world is full of weird unsaid implications like this).
However, I think in this case, 128 bit integers will either be disallowed outside asm! and so cannot leak into asm! and cause problems, or, they're represented as a pair of u64 or whatever, and so still won't cause asm! problems with unrepresentable types.
Not exactly: this is still limited to primitive types and SIMD vectors.
Yeah, we'd like to allow any type here, not sure if that's easiest to do in this PR or a follow-up (or if it's even possible to allow any type). It's certainly a little weird having an IR in asm!, arbitrary types are just... regular SSA IDs that look exactly like primitive types.
There was a problem hiding this comment.
+1 to allowing aggregate Sized types - I've run into this explicitly whilst working on EmbarkStudios/rust-gpu#8 and it's blocking for some of the stuff I'd like to do there. Things get a lot trickier if we need to somehow deconstruct the type into its constituents, and this would also be a pessimisation for the generated code.
| None => { | ||
| let found_supported_ty = match reg_class.supported_types(asm_arch) { | ||
| // FIXME(eddyb) consider skipping the "cannot use value of type" error | ||
| // above, letting the codegen backend handle non-scalar/vector types. |
There was a problem hiding this comment.
We need to do this as part of the type-checking passes since we want to validate these before monomorphization.
There was a problem hiding this comment.
I meant specifically for the Any case. AFAIK SPIR-V should be able to handle any Sized value (similar to LLVM "first-class aggregrates" but even more first-class).
|
Closing this as inactive after a discussion with the author |
Follow-up to #78950, which hardcoded
I8, I16, I32, I64, F32, F64as the supported types for SPIR-Vasm!.This PR lifts that limitation and allows any
InlineAsmType, as therust-gpubackend can support any SPIR-V SSA value type.However, the general type restriction to scalars (integers, floats, pointers) and vectors thereof, remains, as lifting that felt like a more drastic change, but it seems like it might be necessary soon, so if there are no objections, I can also that in this PR.
EDIT: see EmbarkStudios/rust-gpu#256 (comment) for example usecase.
cc @khyperia r? @Amanieu