llvm dev - Mar 2014 - [LLVMdev] RFC - Adding an optimization report facility?

----- 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

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

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

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.
>
Why not just using the line table in -gline-tables-only? These reports will
need to latch on arbitrary instructions, not just loop headers. As more
transformations use the infrastructure, they will want to emit the report
on whatever instruction they triggered on.

Diego.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140307/20c4ee55/attachment.html>

----- Original Message -----
> From: "Diego Novillo" <dnovillo at google.com>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "Chris Lattner" <clattner at apple.com>, "LLVM
Developers Mailing List" <llvmdev at cs.uiuc.edu>
> Sent: Friday, March 7, 2014 8:07:19 AM
> Subject: Re: [LLVMdev] RFC - Adding an optimization report facility?
> 
> 
> 
> 
> 
> 
> 
> On Thu, Mar 6, 2014 at 7:08 PM, Hal Finkel < hfinkel at anl.gov >
wrote:
> 
> 
> 
> 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.
> 
> 
> 
> Why not just using the line table in -gline-tables-only? These
> reports will need to latch on arbitrary instructions, not just loop
> headers. As more transformations use the infrastructure, they will
> want to emit the report on whatever instruction they triggered on.
I'd prefer that we not do that; although we can certainly use debugging
information to enhance the reporting (to include variable names and the like). I
prefer the 'srcloc' on loops solution for two reasons:

 1. It does not force users to include debugging symbols just to get
optimization reports and, more importantly,

 2. Using srcloc is more accurate: If we include only line table information
then we miss column information, and so we can't correctly identify a loop
with multiple loops per line (and those that arise from macro expansion). This
is a real deal-breaker for me.

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