[PATCH] D87233: [POC][DebugInfo] Use entry values within IR

Djordje Todorovic via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Oct 9 10:01:26 PDT 2020


djtodoro added a comment.

In D87233#2321073 <https://reviews.llvm.org/D87233#2321073>, @djtodoro wrote:

> In D87233#2316204 <https://reviews.llvm.org/D87233#2316204>, @dstenb wrote:
>
>> If I understand this correctly, the new `{EntryValue, EntryExpr}` operands do, if `EntryExpr` is not undef, specify a location that is identical to the dbg.value's current `{Value, Expr}` operands, but with DW_OP_LLVM_entry_value implicitly being applied to `EntryValue` before `EntryExpr`. Is that correct?
>
> Yes, that is correct.
>
>> If so, just throwing out some questions (sorry in case I have overlooked the answers for this in the implementation):
>>
>> - I assume that we are only interested in `EntryValue` operands that are `Argument` values? Should the verifier catch that? Or is there some case where it could anything else than an `Argument`?
>
> I think we should extend the `Verifier` with some kind of support for this. Not sure at the moment how we are going to handle this:
>
>   fn(%param) {
>   ...
>   }
>   
>   isa<Argument>(%param) ==>true
>   isa<Argument>(%param.something) ==> false (something could be `addr`)
>
> Actually, I extended the `Verifier` locally, and I am catching some cases during the `replaceAllUsesWith()` where the entry value needs to be handled differently, e.g.:
>
>   llvm.dbg.value(%p1, !var_p1, !DIExpr(), %p1, !DIExpr()) becomes llvm.dbg.value(i32 0, !var_p1, !DIExpr(), i32 0, !DIExpr())
>
> but we want the entry value to be an undef in this situation, so I am wondering whether we need a new representation of the entry-value, something like `MetadataAsEntryValue`, so we can invalidate such nodes in an efficent way.
>
>> - What should happen in cases where the dbg.values `Value` operand already is an `Argument`? Do we need to specify that value in the `EntryValue` operand also to ensure that entry values can be emitted?
>
> We should, since the `Argument` (from some point) can start depending on different entry value, please consider this case:
>
>   void fn (int p1, int p2) {
>      ...
>      p1 = p2;
>   }
>
> And the intrinsics would be:
>
>   llvm.dbg.value(%p1, !var_p1, !DIExpr(), %p1, !DIExpr())
>   llvm.dbg.value(%p2, !var_p1, !DIExpr(), %p2, !DIExpr())

!var_p2, sorry for my mistake

>   ....
>   llvm.dbg.value(%p1, !var_p1, !DIExpr(), %p2, !DIExpr()) <=== p1 is an argument, but it depends on different entry value




CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D87233/new/

https://reviews.llvm.org/D87233



More information about the llvm-commits mailing list