[PATCH] D41697: [DebugInfo][Metadata] Add support for a DIExpression as 'count' field of DISubrange.

Adrian Prantl via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Jan 8 09:00:17 PST 2018


aprantl added a comment.

In https://reviews.llvm.org/D41697#969702, @sdesmalen wrote:

> In https://reviews.llvm.org/D41697#968546, @aprantl wrote:
>
> > The interesting question here is again how to best bind the location to the rest of the DIExpression. For regular variables we use the dbg.value intrinsic to do this:
> >
> >   %ptr = ...  ; in our example, a pointer to the variable
> >   call @llvm.dbg.value(metadata %ptr, metadata !DIVariable(name: "x", ...), metadata !DIExpression(DW_OP_deref))
> >   
> >
> > This way metadata never points back to IR, and DIExpressions can be shared by multiple intrinsics.
> >
> > As you proposed, we can create a pseudo-variable to inject a location into a DIRange:
> >
> >   %length = load i32 %array...
> >   call @llvm.dbg.value(metadata %length, metadata !1, metadata !DIExpression())
> >   ...
> >   !1 = DIVariable(name: "$count", ...)
> >   !2 = !DIRange(count: metadata !1)
> >   
> >
> > A couple of questions now pop up:
> >
> > - It looks like we are dropping the DIExpression because we link the DIVariable to the DIRange, not the dbg.value. Note that many LLVM optimizations augment DIExpressions.
>
>
> I'm wondering why you're saying that the DIExpression is dropped? If we create a pseudo-variable like above, and the DIExpression is not empty, will it not just create a location list with the added expression to each location expression in the list? We can then reference the variable (with its own location list) from our count field?


This looks like a mistake on my side. I wrote this before I understood that the idea is to reference the variable DIE with its own location list from the DW_TAG_subrange.

> 
> 
>> This doesn't solve the problem of how to combine two variables in one expression, but to me it looks like this question can be resolved independently by providing a mechanism for doing so in llvm.dbg.value.
> 
> Agreed!
> 
>> So long story short, I think your proposal is good.
> 
> Good to hear, thanks for digging into this and helping me understand the right way forward!




https://reviews.llvm.org/D41697





More information about the llvm-commits mailing list