<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">Well, I haven’t seen that GCC is emitting more than one DW_TAG_label per label either. So maybe clang is on the same “level” now (or I haven’t triggered that kind of optimization where you get several DW_TAG_label when using GCC).<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Maybe setting breakpoints on labels aren’t supposed to be that safe when using -O1 and higher (you aren’t guaranteed that you get a break every time execution passes the label).<o:p></o:p></p>
<p class="MsoNormal">Or we should try to emit multiple DW_TAG_labels with the same name to see what happens.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">This is not that important to me, just something I discovered when trying out the new feature. I thought that perhaps this was well known and in the category “not done yet / work still ongoing”.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">/Björn<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b>From:</b> David Blaikie <dblaikie@gmail.com> <br>
<b>Sent:</b> den 30 januari 2019 19:40<br>
<b>To:</b> Björn Pettersson A <bjorn.a.pettersson@ericsson.com><br>
<b>Cc:</b> Adrian Prantl <aprantl@apple.com>; llvm-dev <hsiangkai@gmail.com>; llvm-dev@lists.llvm.org<br>
<b>Subject:</b> Re: [llvm-dev] [RFC] Generate Debug Information for Labels in Function<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">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:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">
<p class="MsoNormal">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" 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" 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" 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" 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" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><o:p></o:p></p>
</blockquote>
</div>
</div>
</div>
</body>
</html>