#rust-lang

what's the argument for *non-intrinsic* SIMD?

that LLVM can't handle newtype SIMD wrappers?

in my ideal world, rustc would have SIMD vector types for all reasonable bitwidths

and have all SIMD intrinsics for the given platform, that generate the instruction even if not supported

and libraries that want strongly-typed stuff should use `#[repr(newtype)]` wrappers

the only disadvantage is that you can't use `.k` syntax for shuffles, because no types

you want to have SIMD stable

LLVM intrinsics are not stable

est31: that's why you use instructions from the architecture manual

yes

these are **** stable

rock-stable

but if you directly use the instructions and not LLVM intrinsics, it may not be transparent to LLVM

so you might miss optimisations

which is I think the whole point of intinsics, no?

do people mix user optimizations + SIMD?

I mean, compiler optimizations and SIMD?

autovectorisation is something different from manual SIMD use

just dunno, if you do b = a + a + a +a then the compiler which knows what + means can optimise that to c = a+ a; b = c+ c

arielby: I think the argument against inline asm is regalloc

arielby: but clang has everything we need for LLVM

clang has IR tests for all SIMD intrinsics that are not LLVM intrinsics

eddyb: I think actual inline asm breaks LLVM's optimizer

s/IR tests/IR and assembly/ (I think)