Change LanesAtMost32 to LanesAtMost64 (or possibly remove the lane limit altogether)

[calebzulawski]

We would like to support at least 64-lane vectors (to allow AVX-512 vectors of u8) but there is an aarch64 codegen issue (rust-lang/rust#84020).

Once that issue is solved we can increase the lane limit.

[workingjubilee]

I believe we should consider an alternative to the use of actual numbers in the name if we are going to wind up changing them around based on these codegen vagaries.

[Lokathor]

since it's a dumb temporary limit just call it LanesAtMost

[workingjubilee]

alternatively we can use a const fn and change the internal implementation without having to remove impls for things, which is still backwards-incompatible but in a different way! :D

[calebzulawski]

I'm not actually positive it's a temporary limit, unless we're planning on requiring all backends to support up to usize::MAX lanes (or okay with monomorphization errors). Also it's not clear what we're going to do about non-power-of-two lane counts.

But I agree about renaming it. Maybe something more like ValidLanes?

[thomcc]

OTOH, having the count in the name explains what you have to do to fix the error

[workingjubilee]

We discussed this in the meeting and decided that since we really don't want to go below 32, because we consider AVX2 support important, it's fine to leave it with this name as it is.

Also, that the aarch64 codegen problem should be considered as blocking stabilization until we understand why.

[calebzulawski]

Updated the title of this issue to reflect some expressed sentiment that maybe this trait shouldn't exist at all.

We should probably revisit in the future, but it may be appropriate to just produce a monomorphization error. The compiler currently produces one if the size exceeds some implementation-defined value (65535 lanes, I think), but the error is not very descriptive. If we can improve the error reporting, maybe we can remove this trait altogether.

[BurntSushi]

@calebzulawski IIRC, monomorphization errors are undesirable. As I had understood it, I had thought rustc was developed in such a way as to totally avoid surfacing monomorphization errors to end users. But I don't have a ton of context on that. It might be wise to ping the compiler team on something like this. (If only to discover whether monomorphization errors are a "hard no" or not.)

[calebzulawski]

Yeah, that would definitely be a good idea. Realistically it's extremely unlikely to encounter the error in "normal" code, but if it's an absolute no we need to keep the trait. We could also explore using a lane count type smaller than usize, though that seems hacky.

[calebzulawski]

Actually, I forgot the trait is also preventing sizes that aren't a power of two... so fairly easy to get wrong. Still worth discussing, I think.

[programmerjake]

well, technically arrays also have monomorphization errors: [0i32; !0] should fail to compile. I think a monomorphization error is fine for the case of a huge lane count, but for now we should keep LanesAtMost32 and rename it to LanesArePowerOf2 (or similar), and strive to eventually remove it completely (or just leave it as a trait you can use but remove it from all the bounds in core::simd, we aren't the only ones who like powers-of-2).