----- 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
Diego Novillo
2014-Mar-07 15:25 UTC
[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. 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. Diego.
----- 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
Tobias Grosser
2014-Mar-10 09:35 UTC
[LLVMdev] RFC - Adding an optimization report facility?
On 03/07/2014 03:16 PM, Hal Finkel wrote:> ----- Original Message ----- >> From: "Diego Novillo" <dnovillo at google.com>>> 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. >This is an interesting discussion to have. I currently use line-table debug info and this work very well, with the only exception that line-table information currently needs to be enabled manually. As this could probably be enabled automatically for the users, this does not seem like an unsolvable problems. Using srcloc sounds like an interesting alternative, but I have some questions. 1) How does this work with LTO? Do soclocs actually store information about the source file? Or just the offset? 2) Why are soclocs better when macro-expanding? I really have no idea. A brief explanation not may be sufficient. 3) What about implicit loops e.g. ->begin, ->end Can we even emit soclocs for implicit loops e.g. formed by C++ iterators or range loops? 4) Does the preserving behavior of socs differ from debug info? Will they also be kept on 'best effort'? Do we need all passes (e.g. loop rotate) to preserve socs similar to debug info? Thanks, Tobias
Diego Novillo
2014-Mar-10 14:57 UTC
[LLVMdev] RFC - Adding an optimization report facility?
On Mon, Mar 10, 2014 at 5:35 AM, Tobias Grosser <tobias at grosser.es> wrote:> This is an interesting discussion to have. I currently use line-table debug > info and this work very well, with the only exception that line-table > information currently needs to be enabled manually. As this could probably > be enabled automatically for the users, this does not seem like an > unsolvable problems.Yes. I don't think enabling -gline-tables-only would be a problem when -R is used. It gives us precisely the information we need. Diego.