[LLVMdev] RFC - Adding an optimization report facility?

Hal Finkel hfinkel at anl.gov
Fri Mar 7 08:44:58 PST 2014


----- 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 9:25:12 AM
> Subject: Re: [LLVMdev] RFC - Adding an optimization report facility?
> 
> On Fri, Mar 7, 2014 at 9:16 AM, Hal Finkel <hfinkel at anl.gov> wrote:
> >
> >
> > 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,
> 
> Neither does -gline-tables-only.  In fact, we could silently turn on
> just the generation of src locs and not emit them to the object.
> 
> >
> >  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.
> 
> We don't need column information.  This situation is why I added
> dwarf
> discriminator support recently.  It doesn't matter if the whole
> program is in one line, we will be able to distinguish the location
> of
> the loops via the loop hierarchy and the discriminator values.  This
> is similar to how we use discriminators for sample profiling.

Ah, neat! :-)

> 
> I don't want to focus just on loops.  We should be able to do
> optimization reports on arbitrary instructions. It's true that we
> could limit generation of src locs for major constructs at first, but
> I'm not sure it's worth the effort.

I agree that we don't want to focus just on loops, but loops and functions are obviously a major use case, and tagging them is feasible. If using discriminators can do the same and more, then I'm fine with that too!

Thanks again,
Hal

> 
> 
> Diego.
> 

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



More information about the llvm-dev mailing list