[LLVMdev] RFC - Adding an optimization report facility? (original) (raw)

Hal Finkel hfinkel at anl.gov
Fri Mar 7 06:16:29 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 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

More information about the llvm-dev mailing list