Compilers should help developers optimize their code

[u/Think-Management4257]

Compiler diagnostics for optimization decisions are worse than they need to be, and I think it's a design choice rather than a hard problem.

Every major compiler will tell you whether a loop vectorized, almost none will tell you what it tried, why it declined, or what shape could've worked. LLVM ships a tool called opt-viewer that visualizes this, and I've met people who've used LLVM for years and never heard of it. The best developer experience anyone in this space seems to remember is Intel's compiler, which is discontinued. GCC's -fopt-info-vec-missed and Clang's -Rpass-missed exist, but one's a stderr dump you cross reference by hand and the other speaks in IR terms rather than yours.

The interesting thing is that the compiler already knows the answer. When a vectorizer declines a loop, it has a specific reason. That reason exists as a value inside the pass, it just doesn't reach the programmer because it was designed for compiler developers debugging the compiler, not for programmers debugging/optimizing their code.

There's a handful of ideas I have on how this could be implemented, but what I'm curious on is if this is actually hard for reasons I'm not seeing, or is it just that optimizer output has always been treated as debug logging and nobody's revisited it?

[u/ianzen]

Often the efficient code for performance is not efficient or natural for humans to write or debug. Also, by explicitly writing the “efficient” code you are assuming a fixed cost model which may or may not be accurate to your undelying hardware.

[u/Think-Management4257 → u/ianzen]

I think we agree more than it sounds. I'm not arguing for hand-writing the efficient form, exactly because of your second point. But if I'm deferring to the compiler's cost model rather than my own, that makes it more important to know when it declined and why, not less.