> On Oct 10, 2018, at 12:18 PM, via llvm-commits <llvm-comm...@lists.llvm.org> > wrote: > > > >> -----Original Message----- >> From: jing...@apple.com [mailto:jing...@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 <v...@apple.com> wrote: >>> >>>> On Oct 10, 2018, at 9:16 AM, Matthias Braun <ma...@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. _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev