Support non-power-of-two vector lengths.

[calebzulawski]

In rust-lang/rust#80652 I disabled non-power-of-two vector lengths to deconflict stdsimd and cg_clif development. Power-of-two vectors are typically sufficient, but there was at least one crate using length-3 vectors (yoanlcq/vek#66). It would be nice to reenable these at some point, which would require support from cranelift. Perhaps a feature request should be filed with cranelift?

cc @bjorn3

[thomcc]

TBH I worry that supporting this will cause way more pain by complicating the semantics compared to the value in supporting the use cases.

1. Concretely, with this we'd have explicit always-padding/uninitialized/undefined fields in some of the simd types.

   This feels dangerous, like it will lead to (likely latent) UB in peoples code the same way working with structs that have padding bytes is a headache in low level code, which I'd generally expect a lot of SIMD code to be.

2. The underlying intrinsics will still read these padding/uninit fields them and mix them into the result in a way that might be problematic in a number of ways.

   Consider comparing 2 vec3s and producing a integer bitmask.

   The ideal ideal would probably be the least significant 3 bits set and the rest are zeros. Comparison would produce a 3xN mask with one uninitialized field, but conversion to in integer will produce 0b0000_UZYX, where U is uninitialized.

   That is to say, there's an undef bit, but as (at least) LLVM doesn't track this stuff at the bitwise level, the whole byte is undef... So, maybe simd_bitmask is implemented in a way to fix this, but I'd be very concerned, because as the real operations have to read the bit in question, it seems hard to guarantee robustly.

3. I suspect these would be semantically second-class still. That is:

   There are several behaviors that are currently consistent across all vectors which now would not be consistent for these. Example: size being easily computable from the element count, alignment, repr(simd) being soundly transmutable to/from bytes...

   Several questions exist whose answer is: "it behaves like the next power of two up" that the actual behavior should probably be that way too. For example: everything about layout again, simd_ffi, asm, ...

4. What if there's an arch in the future that ends up modeling non-POT vectors and then doesn't map well to the "uses next power of two up"? I think this is unlikely, but I think we should shy away from defining behavior if we can avoid it.

5. While it will could make programming easier for this user, I strongly suspect that it will cause many future bugs for other users as people make assumptions about the number of elements being a multiple of the size, assume there are no padding bytes, ... (basically all the weird questions in 3)

6. It seems to me like this wouldn't actually help veks code migrate to core::simd very much anyway, would it? repr(simd) isn't stabilizing with core::simd?

   If it isn't: to use core_simd, vek almost certainly wrap our types to define its own functionality, at which point it could hide 4th field of the f32x4 from the public the vec3.

   vek could even keep field access by doing the fields-only-exist-via-{Deref,DerefMut} trick: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=6b1799bb4796514d2a6823c519e71bb1

   If it is, I think a lot of design work has to be done on it that hasn't been begun.

That's all to say: I'm kind of... pretty strongly opposed. If we do this it should be a decision made carefully and weighing all these things (and perhaps more) against the benefits.

---

One note is: if #[repr(simd)] is staying unstable forever, I think it would be fine to support this if it's unobtrusive to a compiler. My objections center on:

1. it being bad and weird in the core::simd API, and
2. it being semantically very bizarre and the kind of thing that sounds better off avoiding rather than trying to specify.

None of these apply to unstable features, which I don't have strong feelings on.

[calebzulawski]

In my opinion, if you are doing things that depend on the layout of a type, you need to ensure that you are properly handling the layout. The vector types already impose architecture-specific alignment implications, I don't think padding implications are particularly onerous. If you want to determine the size of a type, you should use core::mem::size_of and not make assumptions.

I also think it should be pointed out that LLVM entirely supports non-power-of-two vectors (ignoring floating-point exceptions). The limitation here really just comes from cranelift.

Overall I don't think this is about vek, vek only illustrates that there is a desire for non-power-of-two vector lengths. I'm a little confused why it would be weird in the std::simd API, as far as the API is concerned I believe it should be completely length-agnostic.

I do think this is a non-critical issue though, and can definitely be ignored for the time being.

[programmerjake]

@thomcc

4. What if there's an arch in the future that ends up modeling non-POT vectors and then doesn't map well to the "uses next power of two up"? I think this is unlikely, but I think we should shy away from defining behavior if we can avoid it.

both of RISC-V V and SimpleV natively support non-power-of-2 vector lengths; for SimpleV, the in-memory layout is the same as an array with the same length.

[thomcc]

both of RISC-V V and SimpleV natively support non-power-of-2 vector lengths; for SimpleV, the in-memory layout is the same as an array with the same length.

This is a far more compelling reason to support them IMO.

[workingjubilee]

Graphics code usually defers to the GPU, which has subtle but important differences from a typical SIMD register, but it is still useful to consider for our purposes, as a comparison point, if nothing else. And observationally GPUs handle Vec3 inputs by simply using a Vec4 in execution with a dummy value set in the 4th lane, but only use the first 3 lanes otherwise. The savings are on space on the hard drive and in RAM, basically, at the cost of complicating marshalling the data into the stream processors.

That actually a rather lot of programmers basically are okay with this quirk and, while there's some debate over whether or not they should just shove something in the spare element slot and get the advantage of fully aligned accesses when the data is on the CPU, they manage just fine without anything going particularly bad, seems to suggest we'll be okay.

Arm SVE is even more imminent as variable lane silicon that will be available on servers sometime Soon™ (I mean, it's probably already available in HPC land, but I mean for mere mortals who "just" have a big server) and it also can land on non-power-of-2 values for lane bitwidths, though admittedly, always a multiple of 128 bits.

[workingjubilee]

Filed https://github.com/bjorn3/rustc_codegen_cranelift/issues/1136 for now.

Also filing that reminded me that https://github.com/WebAssembly/flexible-vectors/ exists.

[bjorn3]

Glam needs non-power-of-two vectors on SPIR-V.

[XAMPPRocky]

Hey, just wanted to note that the restriction introduced in rust-lang/rust#80652 breaks a lot of code for the rust-gpu spirv-unknown-unknown target, and prevents us from upgrading our compiler to the latest nightly, as SPIR-V has length-3 vectors (x, y, z), which we're using through the glam. In Vulkan these are defined as having a size of 12 and an alignment of 16.

The stated reason for the restriction is the lack of support in Cranelift, however this isn't a concern for us, as our backend does support non-power-of-two SIMD types. Would it be possible to re-enable it just for the rustc_codegen_spirv backend or when compiling for the spirv-unknown-unknown target? This would allow us to upgrade our code on the latest nightly, while keeping the restriction for cranelift.

[calebzulawski]

Perhaps we should revert the power-of-two restriction (not the entire patch as it fixes an ICE) and just allow cg_clif to error if it encounters one? There doesn't seem to be an obvious solution other than keeping #[repr(simd)] perma-unstable (and a little hacky?) pending cranelift support. @workingjubilee suggested GPU targets as a potential user of non-power-of-two vectors from the start and it didn't seem to take long to run into that...

[workingjubilee]

I agree. Is cranelift only used for wasm targeting right now?