[LLVMdev] RFC - Adding an optimization report facility?

[Eric Christopher]

On Thu, Mar 6, 2014 at 11:07 AM, Diego Novillo <dnovillo at google.com> 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:
>
> 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.
>

Yes please.

-eric

>
> Thanks. Diego.
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>