[PATCH] D45024: [DebugInfo] Add DILabel metadata and intrinsic llvm.dbg.label.

David Blaikie via llvm-commits llvm-commits at lists.llvm.org
Thu Apr 5 17:35:38 PDT 2018


Probably best not to create another list on the DISubprogram - you might be
able to generalize the existing list to contain "anything that might be
optimized out"

Katya (CC'd), over at Sony, has been looking at a similar issue/possible
change to move function-local using declarations/directives into such a
list as well.

On Thu, Apr 5, 2018 at 5:32 PM Hsiangkai Wang via Phabricator <
reviews at reviews.llvm.org> wrote:

> HsiangKai added a comment.
>
> In https://reviews.llvm.org/D45024#1059028, @aprantl wrote:
>
> > In https://reviews.llvm.org/D45024#1058953, @probinson wrote:
> >
> > > > 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.
> > >
> > > Hmm if I compile a function containing 3 labels and the debugger knows
> about only 2, I might think the compiler has a bug.
> > >  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.
> >
> >
> > 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.
>
>
> I agree. I think the label information should be kept even intrinsic are
> optimized out such that users could query source code around labels. I will
> create the labels list in DISubprogram and resend the patch. Thanks.
>
>
> Repository:
>   rL LLVM
>
> https://reviews.llvm.org/D45024
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20180406/69617e21/attachment.html>


More information about the llvm-commits mailing list