[PATCH] LowerDbgDeclare - get rid of redundant dbg.values when an alloca survives optimization

[Robinson, Paul]

> -----Original Message-----
> From: Eric Christopher [mailto:echristo at gmail.com]
> Sent: Monday, March 31, 2014 9:31 AM
> To: Robinson, Paul
> Cc: Adrian Prantl; David Blaikie; llvm-commits
> Subject: Re: [PATCH] LowerDbgDeclare - get rid of redundant dbg.values
> when an alloca survives optimization
> 
> On Mon, Mar 31, 2014 at 9:25 AM, Robinson, Paul
> <Paul_Robinson at playstation.sony.com> wrote:
> >> -----Original Message-----
> >> From: llvm-commits-bounces at cs.uiuc.edu [mailto:llvm-commits-
> >> bounces at cs.uiuc.edu] On Behalf Of Adrian Prantl
> >> Sent: Monday, March 31, 2014 8:58 AM
> >> To: David Blaikie
> >> Cc: llvm-commits
> >> Subject: Re: [PATCH] LowerDbgDeclare - get rid of redundant
> dbg.values
> >> when an alloca survives optimization
> >>
> >>
> >> On Mar 30, 2014, at 12:02 PM, David Blaikie <dblaikie at gmail.com>
> wrote:
> >>
> >> > When you say "dropping all dbg.declares" - do you mean we're
> removing
> >> > that intrinsic from LLVM entirely (ie: it won't exist) or that we
> >> > "drop" dbg.declares in IR by removing them at some point in the
> middle
> >> > end?
> >>
> >> I'm not sure if I understand this question entirely, but yes,
> >> LowerDbgDeclare will lower a dbg.declare into multiple dbg.values
> (one
> >> for each use) and then delete the dbg.declare.
> >
> > In terms of information content, it seems like we could eliminate the
> > dbg.declare intrinsic entirely by having the frontend attach one more
> bit
> > of metadata to the associated alloca, which already has two of the
> three
> > bits of info that dbg.declare has.
> >
> > Given the number of -g optimization issues we've found (without really
> > trying) it might be worth thinking about how to eliminate dbg.value
> also.
> 
> And keep in mind here that a lot of them were fixed, just years ago
> and they've crept back in. I think to ensure debug info not affecting
> optimization we're going to need to make it easier for pass writers to
> keep debug information up to date.
> 
> -eric

Right, these are the flip sides of the same issue.  Eliminating the
dbg.value intrinsic means optimizations will no longer have to
(a) notice and ignore the instruction (b) correctly, which will help
them generate the same code with/without -g, and given the barriers
to testing passes with/without -g that feels like a good thing. But
value tracking for debug info purposes becomes less automatic, and
it would be good to have a Cunning Plan to address that.  Sadly I'm
right out of Cunning Plans at the moment.
--paulr