<div dir="ltr">Rather than adding another list (if/when it comes to that) - we might want to generalize the existing list to contain any/all local entities.</div><br><div class="gmail_quote"><div dir="ltr">On Thu, Apr 5, 2018 at 3:38 PM Adrian Prantl via Phabricator <<a href="mailto:reviews@reviews.llvm.org">reviews@reviews.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">aprantl added a comment.<br>
<br>
In <a href="https://reviews.llvm.org/D45024#1058953" rel="noreferrer" target="_blank">https://reviews.llvm.org/D45024#1058953</a>, @probinson wrote:<br>
<br>
> > My understanding was that in the latest revision of the design we don't have anywhere to attach the DILabel to when it is optimized away. If we do care about DILabels that have been optimized away (I don't see why we would want to) we would have to add a list of labels to the DISubprogram similar to how we keep dead variables around. But I don't htink that that is worth it.<br>
><br>
> Hmm if I compile a function containing 3 labels and the debugger knows about only 2, I might think the compiler has a bug.<br>
>  We keep dead variables around so we can correctly report they have been optimized away.  Thinking ahead to supporting languages where labels are far more common than in C/C++ (for example I know the OpenVMS guys will want to support COBOL) I think a labels list might be appropriate.<br>
<br>
<br>
In the end I'm fine with both variants, but if we go for the line field in the DILabel I think we should also implement support for the labels list in DISubprogram or at least document our intention to add this clearly.<br>
<br>
<br>
Repository:<br>
  rL LLVM<br>
<br>
<a href="https://reviews.llvm.org/D45024" rel="noreferrer" target="_blank">https://reviews.llvm.org/D45024</a><br>
<br>
<br>
<br>
</blockquote></div>