[yunnpp]

How is that different from any other compiler optimization?

And what does the last statement in the quote mean anyway? When is performance "predictable"; do you freeze the entire toolchain?

And what is the alternative? Handroll manual SIMD code for every possible architecture you may target?

If you're writing C++, you're already rolling on decades of compiler optimization. You return by value because it makes code more readable and safer and rely on RVO. You write functions to abstract and rely on the compiler inlining. When it doesn't work for your specific target/toolchain, you may decide to handroll stuff. The proof that you're banking on the compiler is that if you run a debug build of any non-trivial program, it runs like absolute dogshit.

[spider-mario]

> How is that different from any other compiler optimization?

When it can be single-handedly responsible for an 8× speedup, you might not want to rely as much on the compiler as in the case of smaller, cumulative optimisations.

> And what is the alternative? Handroll manual SIMD code for every possible architecture you may target?

Use a library like Highway? https://github.com/google/highway

[spider-mario]

Forgot to add: using Highway also means that you can detect and take advantage of e.g. AVX2 or AVX-512 in one binary that still works on CPUs without those instruction sets, whereas relying on autovectorisation would mean having to build with `-mavx2`, `-mavx512`, etc. which means that pretty much no one who relies on prebuilt binaries would get them.