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

[Eric Christopher via llvm-dev]

Yeah, I'm with you here. I don't think there's any particular debug info
gain to having debug info on materializing a constant either.

Vedant: Ultimately I think I'm in favor of this plan.

Thanks!

-eric

On Wed, Jun 20, 2018 at 4:32 PM Matthias Braun via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> 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 <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> wrote:
>
>
> On Tue, Jun 19, 2018 at 5:46 PM Vedant Kumar <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
>
>
> _______________________________________________
> 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/20180621/9860ef2c/attachment.html>