[lldb-dev] [llvm] r343874 - DwarfDebug: Pick next location in case of missing location at block begin

[via llvm-commits]

> -----Original Message-----
> From: Matthias Braun [mailto:matze at braunis.de]
> Sent: Wednesday, October 10, 2018 3:50 PM
> To: Robinson, Paul
> Cc: jingham at apple.com; vsk at apple.com; llvm-commits at lists.llvm.org; lldb-
> dev at lists.llvm.org
> Subject: Re: [lldb-dev] [llvm] r343874 - DwarfDebug: Pick next location in
> case of missing location at block begin
> 
> 
> 
> > On Oct 10, 2018, at 12:18 PM, via llvm-commits <llvm-
> commits at lists.llvm.org> wrote:
> >
> >
> >
> >> -----Original Message-----
> >> From: jingham at apple.com [mailto:jingham at apple.com]
> >> Sent: Wednesday, October 10, 2018 2:20 PM
> >> To: Vedant Kumar
> >> Cc: Robinson, Paul; Vedant Kumar via llvm-commits; LLDB; Matthias Braun
> >> Subject: Re: [lldb-dev] [llvm] r343874 - DwarfDebug: Pick next location
> in
> >> case of missing location at block begin
> >>
> >>
> >>
> >>> On Oct 10, 2018, at 9:54 AM, Vedant Kumar <vsk at apple.com> wrote:
> >>>
> >>>> On Oct 10, 2018, at 9:16 AM, Matthias Braun <matze at braunis.de> wrote:
> >>>>
> >>>> So I haven't worked much on debug info, but here's the explanation
> for
> >> my patches:
> >>>> My original motivation was getting rid of code some code in the llvm
> >> codegen that for spills and reloads just picked the next debug location
> >> around. That just seemed wrong to me, as spills and reloads really are
> >> bookkeeping, we just move values around between registers and memory
> and
> >> none of it is related to anything the user wrote in the source program.
> So
> >> not assigning any debug information felt right for these instructions.
> >> Then people noticed line table bloat because of this and I guess we
> >> assumed that having exact line-0 annotations isn't that useful that it
> >> warrants bloating the debug information...
> >>>
> >>> Right. This doesn't seem any more arbitrary than reusing the previous
> >> instruction location, which we do all the time. I think it's a
> reasonable
> >> tradeoff.
> >
> > For spills and reloads, the next valid source location might be
> reasonable.
> > For top-of-block instructions, I really don't think so; we had this
> issue
> > in FastISel, some years back, and ultimately went with line-0 at top of
> > block because it caused way fewer problems than hoisting the next valid
> > source location.
> 
> I assume what happened in the past was that the previous debug location
> spilled over to the next basic block when the top-of-the-block instruction
> had line-0 set. I can immediately see why that is a problem. And I assume
> that was the case that was overlooked in the past. I cannot see however
> how taking the following location in the same basic block is a problem.

Because those instructions actually do something, and whether variables are
visible and expressions evaluate correctly may depend on those instructions
being executed before the debugger stops.  If you mark them with line 0 the
debugger doesn't stop. If you hoist the next source location, it does.

Spills and reloads in the middle of a block *probably* can be associated
with the next source line without doing any real damage; although it may
turn out that reloads need to attach to the previous source line.  I'd
need to see a variety of examples to be sure, one way or the other.

But long experience has taught me that instructions at the top of a block
really are better off at line 0 than at the next real source line.  If
you can prove they are *always* better off with the next source line, for
all consumers, I'd be very interested to hear about it.

But, this thread is not the best place for that; bring it up on llvm-dev
so other interested parties can see what you're looking for.
--paulr