Comment by nikic
8 years ago
As usual, things aren't quite that simple. While it certainly can happen that the compiler can pessimize carefully crafted SIMD code by applying undesirable transformations, simply not optimizing intrinsics would lead to other problems.
If you consider SIMD code that spans more than just one small function, then it is quite useful if the compiler can SROA (e.g. you pass around an array of vectors instead of having 8 arguments to each function, but still want them to end up in registers eventually), LICM (you're calling a function that needs a constant vector in a loop) or otherwise optimize your code.
If you want the compiler to leave alone your intrinsics, link in an assembly file.
> it is quite useful if the compiler can SROA
__attribute__((always_inline)) / __forceinline usually help.
> LICM (you're calling a function that needs a constant vector in a loop)
I can calculate that vector outside of the loop.
> link in an assembly file.
Way more complex, I need to write outer scalar code in assembly too, need to manually allocate registers, also C++ templates are sometimes very useful for that kind of code.
In 99% of cases intrinsics are good enough for me, but I would love the compilers to leave alone my intrinsics.
Can’t just isolate those in a compilation unit with -O0?
Interesting idea, will try next time.
I usually want to optimize the scalar code outside of the manually-vectorized body of the loops. A function call to that external compilation unit will be slower than inlining I have when everything is in the same unit. However, it could be the call overhead is small enough, obviously need to profile.
1 reply →