[LLVMdev] RFC - Adding an optimization report facility?

[John Leidel (jleidel)]

I seconds Diego's notion that this would be incredibly useful.  

Hal's suggestion of attaching loop-id metadata and 'srcloc' data to candidate loops in the frontend is also sane.  I've seen several older vector compilers do this in order to generate simple compile-time vector reports.  {loads, stores, ops, idioms, ops-under-mask, etc}.  They turn out to be incredibly useful for users.  It would be an interesting bit of research to come up with a relatively standard reporting format for scalar, vector [or simd] and mimd constructs [such as openmp].

cheers
john 


On Mar 6, 2014, at 6:08 PM, Hal Finkel <hfinkel at anl.gov>
 wrote:

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