[LLVMdev] RFC - Adding an optimization report facility?

Diego Novillo dnovillo at google.com
Tue Mar 11 14:39:12 PDT 2014


I have written down my thoughts and added some of the feedback from this
thread. The proposal is probably still sparse, but I would like to start
the discussion so I can shape it into final documentation when we are done
painting the bike shed.

https://docs.google.com/document/d/1FYUatSjZZO-zmFBxjOiuOzAy9mhHA8hqdvklZv68WuQ/edit?usp=sharing

Please add your feedback on the document itself (anyone should be able to
comment) or to this thread.

Tobias, I will look at your patches this week and start producing my own
changes on top of them.


Thanks.  Diego.


On Thu, Mar 6, 2014 at 2:07 PM, 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:
>
>    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/20140311/02e77f9c/attachment.html>


More information about the llvm-dev mailing list