[LLVMdev] RFC - Adding an optimization report facility?

[Gerolf Hoflehner]

This feature will be very useful and I suggest taking a bigger perspective.

Not only the major decisions but also simple optimizations metrics like #<opt_instances>, #spills etc can be useful for performance analysis, comparison and tracking. In addition to metrics locality is helpful, specifically a report at a function level. A good place to start and test the design could be to issue current —stats per function. In practice the users of these reports know the hot functions and like to drill down. 

The reports themselves could offer various levels of verbosity for the user to pick (and the implementer to decide which information to report at which level).

For performance tuning a compiler that also reports why it didn’t apply an optimization can be very useful (like in “I didn’t vectorize because of this dependency.” etc.).

-Gerolf


On Mar 11, 2014, at 2:39 PM, Diego Novillo <dnovillo at google.com> wrote:

> 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:
> 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.
> 
> 
> Thanks. Diego.
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140311/c444c672/attachment.html>