[LLVMdev] RFC - Adding an optimization report facility?

[Diego Novillo]

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:

   1. 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.
   2. The output is unstructured and it often uses pass-specific lingo
   which may confuse someone who just started looking at it.
   3. It forces a debug+asserts build (or at least a build with -UNDEBUG).
   4. 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.


Thanks. Diego.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140306/50de3572/attachment.html>