[LLVMdev] RFC - Adding an optimization report facility?

[Hal Finkel]

----- Original Message -----
> From: "Chris Lattner" <clattner at apple.com>
> To: "Diego Novillo" <dnovillo at google.com>
> Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>
> Sent: Thursday, March 6, 2014 5:54:02 PM
> Subject: Re: [LLVMdev] RFC - Adding an optimization report facility?
> 
> 
> On 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. ...
> 
> 
> 
> 
> 
> 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.
> 
> This is a great idea, and many people would welcome it. Please write
> up a concrete proposals about how this will work, and we can iterate
> on that though.
> 
> 
> 
> 
> 
> 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
> ).
> 
> 
> 
> I'm not sure if this is the best design or not (having never used it)
> - what feedback have you heard from (non-compiler-hacker) people
> trying to use it?
> 
> IMO, the hard part of doing something like this is getting the user
> experience right. It does you no good to say "hey I unrolled a loop"
> if you don't have enough location information to tell the user
> *which* loop got unrolled. The key is to give them actionable
> information, not just the output of -debug :-)

My suggestion is that we start attaching loop-id metadata to loops in the frontend, and then also start attaching 'srcloc' metadata, just like we do for inline asm statements. This way we can pass back the information we need to the frontend for it to identify the loop without too much trouble. There may be a better long-term design, but this seems, at least, like an easy thing to do in the short term.

 -Hal 

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

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory