<div dir="ltr">What does GCC do in situations like this?<br><br>I suspect the rightiest thing to do is probably multiple DW_TAG_labels with the same name, if that's what's happened.<br><br>I guess another question/possibility - what happens if some inline asm references the label? I guess it probably constrains the optimizer not to unroll? Maybe? If the label can be duplicated and inline asm can still correctly reference the label, maybe that's the answer - describe the label the same way inline asm "sees" it.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jan 30, 2019 at 6:04 AM Björn Pettersson A via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">As far as I can see we now get DW_TAG_label on trunk. Nice!<br>
<br>
I also see that there has been some talk about loop unrolling etc. when<br>
discussing this RFC. Was there a consensus on what should happen if we<br>
end up with multiple dbg.label intrinsics for the same label due to<br>
code duplication?<br>
<br>
Here is an example where we get two "#DEBUG_LABEL: main:foo" but only one<br>
DW_TAG_label for "foo": <a href="https://godbolt.org/z/oTpHQp" rel="noreferrer" target="_blank">https://godbolt.org/z/oTpHQp</a><br>
<br>
Maybe that is as expected, or is it allowed to have multiple DW_TAG_label<br>
for the same label name?<br>
<br>
/Björn<br>
<br>
> -----Original Message-----<br>
> From: llvm-dev <<a href="mailto:llvm-dev-bounces@lists.llvm.org" target="_blank">llvm-dev-bounces@lists.llvm.org</a>> On Behalf Of Adrian<br>
> Prantl via llvm-dev<br>
> Sent: den 30 mars 2018 18:40<br>
> To: Adrian Prantl <<a href="mailto:aprantl@apple.com" target="_blank">aprantl@apple.com</a>><br>
> Cc: llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
> Subject: Re: [llvm-dev] [RFC] Generate Debug Information for Labels in<br>
> Function<br>
> <br>
> <br>
> <br>
> > On Mar 30, 2018, at 9:25 AM, Adrian Prantl via llvm-dev <llvm-<br>
> <a href="mailto:dev@lists.llvm.org" target="_blank">dev@lists.llvm.org</a>> wrote:<br>
> ><br>
> ><br>
> ><br>
> >> On Mar 29, 2018, at 11:29 PM, Hsiangkai Wang <<a href="mailto:hsiangkai@gmail.com" target="_blank">hsiangkai@gmail.com</a>><br>
> wrote:<br>
> >><br>
> >> I agree with you. Attach debug metadata to basic block will be a<br>
> >> better solution. I will change my design to convey debug metadata<br>
> >> through basic block instead of intrinsic.<br>
> >><br>
> >> <a href="https://reviews.llvm.org/D45078" rel="noreferrer" target="_blank">https://reviews.llvm.org/D45078</a><br>
> ><br>
> > In this revised design it is now possible to attach a DILabel to a<br>
> BasicBlock. When the basic block is inlined it will be ambiguous to<br>
> which function the DILabel belongs. For instructions, we store the<br>
> inline information in the inlinedAt: field of its DILocation. In order<br>
> to handle inlining for DILabels we have two options:<br>
> ><br>
> >  1. Also attach a DILocation to be associated with the label to carry<br>
> the inline information, and teach the inliner to correctly update the<br>
> DILocation on basic blocks during inlining. This would also solve the<br>
> issue of hypothetical scoped labels that Paul brought up. We'll also<br>
> need to figure out what to do when two labels are being merged by a<br>
> transformation.<br>
> ><br>
> >  2. Teach the inliner to drop all metadata attachments on basic<br>
> blocks.<br>
> ><br>
> > Option (2) is obviously going to be easier to implement and might be<br>
> a good as a first step.<br>
> <br>
> I'm really sorry for not realizing this yesterday, but the problems<br>
> pertaining to inlining made me realize that your original design with<br>
> the dbg.label intrinsic might actually be a better approach especially<br>
> when considering optimized code. We will get inlining support for free<br>
> because it is just another instruction and it can deal with more than<br>
> one label at the same address. It looks a bit more complicated in<br>
> unoptimized code, but that seems like a small price to pay.<br>
> <br>
> We just need to make sure that the backend doesn't get confused when<br>
> loop unrolling duplicates a dbg.label but that should be doable.<br>
> <br>
> -- adrian<br>
> <br>
> ><br>
> >><br>
> >>> That said, perhaps this isn't even necessary. The only information<br>
> that is stored in DILabel is the name of the label (which is redundant<br>
> with the actual name of the label) and its source location, which is<br>
> also stored in the DILocation (!11). I'm wondering if the DILocation of<br>
> a label is even useful. When a debugger user sets a breakpoint of a<br>
> label, we might as well use the location of the first instruction in<br>
> the basic block described by the label, since that is where execution<br>
> will continue.<br>
> >>><br>
> >>> Based on that I think it might be sufficient to have a flag on an<br>
> IR label that marks a user-originated label and triggers the backend to<br>
> create a DW_TAG_label for it. If we do need source location information<br>
> for the DW_TAG_label, we could grab it from the first instruction.<br>
> >> I still think that we should collect debug information from source<br>
> >> code level instead of infer from instructions in the basic block. As<br>
> >> Paul said, "the top instructions in a block do not necessarily have<br>
> a<br>
> >> valid source location." So, I will keep DILabel metadata and remove<br>
> >> llvm.dbg.label intrinsic.<br>
> ><br>
> > I'm still not convinced that this information will be useful to a<br>
> debugger, but if you have a compelling use-case please let me know.<br>
> ><br>
> > -- adrian<br>
> > _______________________________________________<br>
> > LLVM Developers mailing list<br>
> > <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> > <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
> <br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>