So my point stands: If a compiler can't produce vectorised code, the compiler needs to be improved. Spending time on improving the compiler is sustainably spent time. Spending time on programming SIMD in assembly by hand likely is not.

I believe you that the vectorization support at the moment is not good enough, and I completely understand that not everyone can spend time on improving the compiler.

However, it seems you know exactly what a compiler should be able to do and what feedback from the compiler, or annotations for the compiler, would be helpful for your use-cases where optimization somehow didn't figure out what to vectorize.

I was just pointing out that communicating with compiler people and getting them to improve the compiler is likely a better move than asking for better support for inline assembly.

The point is simply that C doesn't have the concepts you want to program with. Vectorization only gets you so far, there are many other things you can do with AVX/SSE. It doesn't need to be ASM, it could be supersets of C instead (like CUDA).

Intrinsic functions for AVX is what I use and I don't see the problem with using those. It sort of is such a superset of C.

In practice a few numerical computations (BLAS, FFTs, etc) are reused a lot by many. It is worth it to write those few libraries in assembly (or at least intrinsics).

For the rest we just have to live with a small performance penalty.

I am just saying "if you want to go the extra mile to get high performance, you can beat compilers". In most scenarios of course it makes most sense to not bother.

I don't see how it's "very hard" in the general case. Compilers have been increasingly cutting programmers out of the loop for 30 years now.

It's the reason we program apps and even games in C++ and not in hand-rolled assembly as we did in the 80s, and why we can use crazily high level languages like JS and still get within an order of magnitude of C with a modern JIT.

However, I don't think it is useful to consider a compiler to be a replacement for programmers. Compilers are tools for programmers. The more time a compiler saves a programmer, the better it is.

I think there is a middle ground between writing inline assembly and fully automatic vectorization that would be less time intensive than manual vectorization and more predictable and available earlier than fully automatic vectorization. I wonder what would have to be done to find it and provide support for it in GCC/LLVM.

You also need to take into account that a huge chunk of the work in SIMD is the need to rearrange your data to be more amenable to the CPU. C++ compilers are very restricted in what they can do for you there.