add simd_splat intrinsic

[folkertdev]

Add simd_splat which lowers to the LLVM canonical splat sequence.

insertelement <N x elem> poison, elem %x, i32 0
shufflevector <N x elem> v0, <N x elem> poison, <N x i32> zeroinitializer

Right now we try to fake it using one of

fn splat(x: u32) -> u32x8 {
    u32x8::from_array([x; 8])
}

or (in stdarch)

fn splat(value: $elem_type) -> $name {
    #[derive(Copy, Clone)]
    #[repr(simd)]
    struct JustOne([$elem_type; 1]);
    let one = JustOne([value]);
    // SAFETY: 0 is always in-bounds because we're shuffling
    // a simd type with exactly one element.
    unsafe { simd_shuffle!(one, one, [0; $len]) }
}

Both of these can confuse the LLVM optimizer, producing sub-par code. Some examples:

• Inlining + target_feature broken in powerpc64 #60637
• Bad codegen for widen followed by ARM vdupq_n_* #137407
• WASM+simd128 codegen of a.simd_eq(Simd::splat(b)).any() deteriorates as width increases #122623
• Array Repeat operator should not use a loop for small sizes #97804

---

As far as I can tell there is no way to provide a fallback implementation for this intrinsic, because there is no const way of evaluating the number of elements (there might be issues beyond that, too). So, I added implementations for all 4 backends.

Both GCC and const-eval appear to have some issues with simd vectors containing pointers. I have a workaround for GCC, but haven't yet been able to make const-eval work. See the comments below.

Currently this just adds the intrinsic, it does not actually use it anywhere yet.

[programmerjake]

this would also be useful for @rust-lang/project-portable-simd

[folkertdev]

r? @workingjubilee (or anyone else with intrinsic/simd knowledge)

[rustbot]

workingjubilee is currently at their maximum review capacity.
They may take a while to respond.

[rustbot]

Some changes occurred to the platform-builtins intrinsics. Make sure the
LLVM backend as well as portable-simd gets adapted for the changes.

cc @antoyo, @GuillaumeGomez, @bjorn3, @calebzulawski, @programmerjake

Some changes occurred to the CTFE machinery

cc @RalfJung, @oli-obk, @lcnr

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

Some changes occurred in compiler/rustc_codegen_gcc

cc @antoyo, @GuillaumeGomez

Some changes occurred to the intrinsics. Make sure the CTFE / Miri interpreter
gets adapted for the changes, if necessary.

cc @rust-lang/miri, @RalfJung, @oli-obk, @lcnr

Some changes occurred to the CTFE / Miri interpreter

cc @rust-lang/miri

[RalfJung]

r=me on the const_eval and codegen_ssa changes.

View changes since this review

[folkertdev]

or make ./x test locally do what CI does. Yeah this bites me basically every time ... anyway should be fixed now.

[RalfJung]

or make ./x test locally do what CI does.

It does, but different CI jobs use different bootstrap.toml values -- some have optimizations enabled, some disabled. Generally this is good for test coverage, except for tests that really care about the exact IR being emitted...

[folkertdev]

I think PR CI should at least catch this, having rollups fail because of it is such a waste of time.

[RalfJung]

Could you file an issue? I think I agree with Jubilee's option of just not applying noopt to codegen tests; those tests are expected to be highly sensitive to optimization flags. However, for some tests it's the opt flags of the standard library build that matter, that could be more tricky to deal with.

[folkertdev]

@bors r=workingjubilee

[rust-bors]

📌 Commit 71f3442 has been approved by workingjubilee

It is now in the queue for this repository.

[workingjubilee]

@RalfJung

nikic already filed an equivalent issue I hadn't seen when I made my comment: #151580