[Joker_vD]

You know, it's always funny to read takes like "A broken compiler forcing you to write explicit SIMD instead of trusting auto-vectorization and coming out 20-30% faster is the best argument I've seen for reading your own generated assembly occasionally instead of assuming the compiler has you covered" because you can quite easily imagine an alternative one like "A broken compiler revealing that the auto-vectorization actually already accounts for 50% of total speed up of O3, and manual reimplementation and code restructuring provided only additional 20% in some scenarios is the best argument I've seen for almost never bothering with hand-crafting assembly anymore".

[spockz]

Is there some way to write unit tests for cases where you know vectorisation should have been applied? I guess micro benchmarks should cover the performance part. We have ArchUnit to cover code structures, it would be nice if something similar exists for generated assembly.

[nananana9]

I've been begging for years for a a [[must_vectorize]] annotation that I can place before a loop I care about, and turn it into a compile error if the compiler can't figure it out.

[Rendello]

Just don't do it like Rust inlining annotations:

<No annotation> – Gently suggests inlining

#[inline] - Really suggests inlining

#[inline(always)] – Really Really suggests inlining (still not guaranteed!)

https://nnethercote.github.io/perf-book/inlining.html

[dupontcyborg]

this would be amazing

[rurban]

The gcc torture test suite has for most vect/ tests ast checks to see such regressions. LLVM missed it.

[spider-mario]

Explicit SIMD doesn’t have to mean hand-crafting assembly (and I don’t think it did in this instance).

[imtringued]

Yeah it's strange how they brushed away that the compiler reached 77% of the hand crafted performance without even trying.