preserve SIMD element type information

[folkertdev]

Preserve the SIMD element type and provide it to LLVM for better optimization.

This is relevant for AArch64 types like int16x4x2_t, see also llvm/llvm-project#181514. Such types are defined like so:

#[repr(simd)]
struct int16x4_t([i16; 4]);

#[repr(C)]
struct int16x4x2_t(pub int16x4_t, pub int16x4_t);

Previously this would be translated to the opaque [2 x <8 x i8>], with this PR it is instead [2 x <4 x i16>]. That change is not relevant for the ABI, but using the correct type prevents bitcasts that can (indeed, do) confuse the LLVM pattern matcher.

This change will make it possible to implement the deinterleaving loads on AArch64 in a portable way (without neon-specific intrinsics), which means that e.g. Miri or the cranelift backend can run them without additional support.

discussion at #t-compiler > loss of vector element type information

[rustbot]

Some changes occurred in compiler/rustc_codegen_gcc

cc @antoyo, @GuillaumeGomez

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

[rustbot]

r? @nnethercote

rustbot has assigned @nnethercote.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler
• compiler expanded to 69 candidates
• Random selection from 11 candidates

[folkertdev]

View changes since the review

the types above are actually used by neon intrinsics. Below are a couple that technically work but are unlikely to come up practically.

Then for any type is smaller than 128-bit padding is added which means the type information is lost (but I think that is needed for ABI reasons?). Larger types are passed indirectly, so the type information is not needed there (but we do still technically provide it, maybe it's useful elsewhere).