[llvm-dev] [RFC] Removing debug locations from ConstantSDNodes

[Matthias Braun via llvm-dev]

FWIW: Debug information on constants feels odd to me. They are just values not something that is executed so conceptually I would not expect them to "happen" at a specific time/place in the program. That said most numbers are copied into registers or stored into memory and that is of course an interesting action. So in the original example I would hope to see debug info on whatever instructions are used to fill the array with values.

That said I'm not familiar with the inner workings of dwarf or other debugger formats, so it may very well be reasonable to backfill the information in a late pass to avoid having assembler instructions without debug info as some people proposed.

- Matthias

> On Jun 20, 2018, at 11:09 AM, via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> DwarfDebug::beginInstruction sets the location to line 0 because otherwise the location is implicitly the same location as the last instruction of the physically preceding block.  That location is often completely unrelated to what's at the top of the new block.  Line 0 isn't great, but at least it's not a complete lie.
> --paulr
>   <>
> From: vsk at apple.com [mailto:vsk at apple.com] 
> Sent: Wednesday, June 20, 2018 1:48 PM
> To: Reid Kleckner
> Cc: Robinson, Paul; llvm-dev; Justin Bogner; David Li; David Blaikie
> Subject: Re: [RFC] Removing debug locations from ConstantSDNodes
>  
> On Jun 19, 2018, at 6:36 PM, Reid Kleckner <rnk at google.com <mailto:rnk at google.com>> wrote:
>  
> On Tue, Jun 19, 2018 at 5:46 PM Vedant Kumar <vsk at apple.com <mailto:vsk at apple.com>> wrote:
> Someone (Reid?) mentioned that we could try sinking constants to their point of first use as an alternative, and (IIUC) create new nodes with distinct DebugLocs for each use of a constant. I don't recall the details of that alternative clearly. Based on my (likely incorrect) understanding of it, dropping locations from constants outright might be simpler.
>  
> Our use case was in fastisel, so things are different. I don't think my solution will help you.
>  
> In our case, users were complaining about code like this:
> volatile int do_something;
> void f() {
>   ++do_something;
>   foo(1, 2, 3);
>   ++do_something;
> }
>  
> We'd generate locations like:
>   .loc line 1
>   incl do_something(%rip)
>   movl $1, %ecx
>   movl $2, %edx
>   movl $3, %r8d
>   .loc line 2 # line 2 starts here, instead of 3 instructions earlier
>   callq foo
>   .loc line 3
>   incl do_something(%rip)
> 
> 
> Our users really wanted the line table entry for line 2 to include the constant materialization code for some VS debugger feature.
>  
> Got it. (For others following along, there's more discussion about this debugger feature in the commit description for r327581.)
> 
> 
> 
> I think if you remove locations from ConstantSDNodes, you might want to add a late pass that propagates source locations backwards onto location-less instructions. This would also avoid some special cases when a basic block starts with an instruction that lacks location information. See CodeViewDebug::beginInstruction and DwarfDebug::beginInstruction for what we do today.
>  
> Interesting, I hadn't considered doing this.
>  
> What happens in the special case where a block starts with a location-less instruction? Ah, I see that CodeViewDebug::beginInstruction does a forward scan to find the first instruction with location. This can fail though: there might not be such an instruction, in which case... I assume we either apply a line-0 location, or nothing at all, similar to Dwarf::beginInstruction?
>  
> It's a bit unclear to me what the benefits of a late pass that backwards-propagated locations would be. I suppose we'd have fewer forward scans in CodeViewDebug::beginInstruction, so is the benefit a compile-time win (which would offset the cost of a late pass)? Would the final debug info quality would be better in some way I'm just missing?
>  
> thanks!
> vedant
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180620/4f7e7be5/attachment.html>