The context of this is performance analysis of generated code. My interest is to trace at a high-level the major decisions done by the various optimizers. For instance, when the inliner decides to inline foo into bar, or the loop unroller decides to unroll a loop N times, or the vectorizer decides to vectorize a loop body.
Many of these details are usually available via -debug-only. However, this has several limitations:
- The output is generally too detailed. Passes will often emit the result of their analysis, what failed, what worked, etc. This is often fine when debugging the pass itself, but it’s too noisy for initial analysis.
- The output is unstructured and it often uses pass-specific lingo which may confuse someone who just started looking at it.
- It forces a debug+asserts build (or at least a build with -UNDEBUG).
- Only one pass at a time can be asked to produce debugging output.
Additionally, I don’t think it’s right to co-opt the -debug-only facility for implementing optimization reports. They have different purposes. An optimization report should simply state what the pass did in fairly terse way. This facilitates initial and comparative analysis. If I want to compare what one compiler did versus the current version, it would be easy to spot what decisions were made by each one.
Clearly, the quality of the information will depend on how many decisions are reported. Not every difference in performance will be detected by comparing optimization reports. But major differences are often due to major passes making slightly different decisions (e.g., the inliner).
My intent is to introduce an optimization report option to LLVM which passes will be able to use to indicate the major decisions they make. Initially, I am tempted to mimic GCC’s -fopt-info (http://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html#index-fopt-info-747).
Before I get too far into this, do folks think this is a good idea? I’m open to reasonable requests on how the facility should work, etc.