[LLVMdev] RFC - Adding an optimization report facility?

[Hal Finkel]

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