bjorn3 (Feb 08 2021 at 20:37): bjorn3 (Feb 08 2021 at 20:37):stdsimd wants to support non power-of-two vector sizes, but Cranelift doesn't have support for this. Could this be added or is this too complex. For reference see https://github.com/bjorn3/rustc_codegen_cranelift/issues/1136 and the pingbacks there.
Chris Fallin (Feb 09 2021 at 02:19):Hmm -- this would be a nontrivial amount of work, and my first instinct is that it should be low-priority as it is still (it seems to me) a niche use-case not supported on most hardware we would run on today
Chris Fallin (Feb 09 2021 at 02:19):that said we can look at generalizing the vector types eventually (i.e. integer-parameterized types, rather than a fixed finite set of 32x4, 64x2, ...) if this need becomes more important
Jubilee (Feb 22 2021 at 17:07):This became pretty non-theoretical pretty quickly, someone else uses rustc with SPIR-V as a target and that uses and emits Vec3 types.
Benjamin Bouvier (Feb 22 2021 at 17:19):@Jubilee thinking about rust-gpu? If so, they're using their own rustc compiler backend implementation, which doesn't rely on cg_clif (or LLVM, for that matter). Thus there's no implied dependency on Cranelift in this particular case.
Jubilee (Feb 22 2021 at 17:20):yep, but it means that enforcing the vector length restriction in the compiler isn't really acceptable, since both have to use the same code path.
Jubilee (Feb 22 2021 at 17:24):So it's not that cranelift has to support emitting that code, but that we can't promise that cg_clif doesn't have to cope with getting fed a f32x3 and then spitting it back in the user's face like an indignant baby during compilation.
Last updated: Dec 23 2024 at 12:05 UTC