ICE with unusual vector sizes

[calebzulawski]

When trying to make a vector with only 3 lanes, the following occurs:

error: internal compiler error: compiler/rustc_codegen_llvm/src/context.rs:448:55: unknown intrinsic 'llvm.ceil.v3f64'

A couple options:

• Only support power-of-two vector lengths. This is probably fine (at least for the MVP) but would probably require a new attribute for restricting the const generic implementation.
• Patch rustc to use the next power of two for ceil etc. Most other ops seem to work fine with unusual vector sizes.

[bjorn3]

Only support power-of-two vector lengths.

Cranelift only has support for power-of-two lengths.

This is probably fine (at least for the MVP) but would probably require a new attribute for restricting the const generic implementation.

Or the layout computation could disallow non power-or-two lengths for #[repr(simd)] types.

Patch rustc to use the next power of two for ceil etc.

For at least x86, non power-of-two lengths are not very efficient. Each load and store would need to use a single instruction for every lane.

[calebzulawski]

For at least x86, non power-of-two lengths are not very efficient. Each load and store would need to use a single instruction for every lane.

x86 does have masked loads and stores but in my experience those are pretty terrible as well.

I do like the idea of adding the check to the repr attribute.

I just encountered another related issue with vectors that are powers of two but too large, such as 128 usizes. It doesn't ICE but it does error. I think this should be allowed since it's trivial to compose smaller vectors. Does cranelift support that?

[bjorn3]

Cranelift uses 16bit lane lengths, but there is a limit on the max lane size that I couldn't quickly figure out. Cranelift theoretically has support for splitting vectors operations when the vectors are too big, but the new backends don't support it yet and for the old backends, I believe it wasn't reliable. I think support should be added in the future though.

[workingjubilee]

I believe our MVP can focus on 2.pow(N) lanes for now without negative consequences, but an actual extension where we simply politely ignore the 8th lane is more elegant, yes. If Cranelift supports up to 65536 lanes then I believe it will satisfy any future lane lengths we care about.

[bjorn3]

Cranelift supports any power of two lane length of up to u16::MAX lanes. (so it actually only supports up to 2^15 lanes) Cranelift stores the log2 of the lane length in the Type struct.

[calebzulawski]

Closed in rust-lang/rust#80652.