> You don’t want to rely on a brittle unpredictable code transformation for performance in this case.
That's somewhat true, but much of the unpredictability could be removed if compilers provided annotations saying "I expect this loop to be vectorized" where the compiler would be forced to report an error if it didn't manage to do it.
Such annotations exist in all major C/C++/Fortran compilers, although not all will error if it goes poorly. Although most of the ones with an HPC focus have some output where they will tell you how they optimized your loop for you.
And then what do you do when you upgrade compilers and the build starts failing?
This isn’t a hypothetical, it happens in real life. Your only option at that point is roll back compilers and hope someone cares about the regression enough to fix it.
The point is the better model is to build the semantics into the language rather than relying on the whims of implementation.
Of course the semantic guarantees will likely be somewhat weak because of differences in ISAs, memory hierarchies, etc.
As fallback, I have unit-tests with a check on both correctness and the instruction count (and # of memory allocations in hot loops). Whereas the cpu cycle-count varies between runs, the instruction count does not.
Linux has good support for performance counters, Windows requires a bit of work.
So in this case, the compiler update would show a regression in the test suite, which needs to be addressed as part of the compiler upgrade.
Of course, having this in the compiler would remove the need for unit tests.
That's somewhat true, but much of the unpredictability could be removed if compilers provided annotations saying "I expect this loop to be vectorized" where the compiler would be forced to report an error if it didn't manage to do it.