[LLVMdev] RFC - Adding an optimization report facility?

[Tobias Grosser]

On 03/06/2014 08:07 PM, Diego Novillo wrote:
> 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.

Hi Diego,

as others already pointed out, I committed the first piece of such an 
infrastructure in LLVM commit 202474 and clang commit 202475. This is
mostly the backend and printing infrastructure.

This should already be functional, even though Alp pointed out there are 
still some open issues with the c-bindings and the verify diagnostic 
consumer (I still need to look into those). The command line options to 
enable this are currently working, but still very basic. Several people 
had ideas how to improve on this, but we did not yet agree on a 
solution. If you are interested in contributing here, that would be 
great. I have myself a patch on the clang-commits mailing list ('tblgen: 
Modularize the diagnostic emitter') which prepares the command line 
infrastructure for possible changes, but the more complicated issue of 
finding a good interface without increasing complexity is still open. 
Also, we still need more in-tree users to
better test the infrastructure and to get an idea of what kind of 
reports we would like to emit (which again can help shaping the command 
line interface). Your thoughts and contributions are highly appreciated.

Cheers,
Tobias