[llvm-dev] [RFC] Generate Debug Information for Labels in Function
Adrian Prantl via llvm-dev
llvm-dev at lists.llvm.org
Fri Mar 30 09:25:10 PDT 2018
> On Mar 29, 2018, at 11:29 PM, Hsiangkai Wang <hsiangkai at gmail.com> wrote:
>
> I agree with you. Attach debug metadata to basic block will be a
> better solution. I will change my design to convey debug metadata
> through basic block instead of intrinsic.
>
> https://reviews.llvm.org/D45078
In this revised design it is now possible to attach a DILabel to a BasicBlock. When the basic block is inlined it will be ambiguous to which function the DILabel belongs. For instructions, we store the inline information in the inlinedAt: field of its DILocation. In order to handle inlining for DILabels we have two options:
1. Also attach a DILocation to be associated with the label to carry the inline information, and teach the inliner to correctly update the DILocation on basic blocks during inlining. This would also solve the issue of hypothetical scoped labels that Paul brought up. We'll also need to figure out what to do when two labels are being merged by a transformation.
2. Teach the inliner to drop all metadata attachments on basic blocks.
Option (2) is obviously going to be easier to implement and might be a good as a first step.
>
>> That said, perhaps this isn't even necessary. The only information that is stored in DILabel is the name of the label (which is redundant with the actual name of the label) and its source location, which is also stored in the DILocation (!11). I'm wondering if the DILocation of a label is even useful. When a debugger user sets a breakpoint of a label, we might as well use the location of the first instruction in the basic block described by the label, since that is where execution will continue.
>>
>> Based on that I think it might be sufficient to have a flag on an IR label that marks a user-originated label and triggers the backend to create a DW_TAG_label for it. If we do need source location information for the DW_TAG_label, we could grab it from the first instruction.
> I still think that we should collect debug information from source
> code level instead of infer from instructions in the basic block. As
> Paul said, "the top instructions in a block do not necessarily have a
> valid source location." So, I will keep DILabel metadata and remove
> llvm.dbg.label intrinsic.
I'm still not convinced that this information will be useful to a debugger, but if you have a compelling use-case please let me know.
-- adrian
More information about the llvm-dev
mailing list