[PATCH] D142160: [mem2reg][debuginfo] Handle op_deref when converting dbg.declare

Felipe de Azevedo Piovezan via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Jan 25 12:43:47 PST 2023


fdeazeve added inline comments.


================
Comment at: llvm/lib/Transforms/Utils/Local.cpp:1534
+  // The former says that the value of the variable is found by doing:
+  // deref(deref(alloca) + 2), whereas the latter is deref(deref(alloca)) + 2.
+  // If the alloca describes the variable itself, i.e. the expression in the
----------------
Orlando wrote:
> aprantl wrote:
> > I'm not sure the second half of this sentence is necessarily true, I think it's more an emergent behavior of the instruction selector, because at the LLVM IR level we don't really distinguish what DWARF calls location description kinds, but it certainly correct that the two are not equivalent.
> > 
> > One thing you could do is define the semantics of `dbg.declare(alloca, var, DIExpression(DW_OP_deref))` as the alloca holding the canonical address of var, *which may not change throughout the entire function*. Patching LangRef this way would allow you to do the kind of transformation that you need here.
> > 
> > I'm also curious if how we defined llvm.dbg.addr() and if it would be of any use here.
> + to everything @aprantl said. Note that dbg.addr may be on the way out - see [[ https://discourse.llvm.org/t/what-is-the-status-of-dbg-addr/62898 | this discourse post ]].
> 
> I could be wrong but I don't think the `dbg.value` in the example looks quite right - IIRC it should end with either a `stack_value` or `deref` operand if the expression is non-empty because `dbg.value`s are //essentially// implicit location descriptions (describing the value of the variable rather than its location).
> I could be wrong but I don't think the dbg.value in the example looks quite right 

It is indeed intentionally wrong, the comment was attempting to explain why doing the conversion of dbg.declare -> dbg.value would be incorrect in that case. I've updated the comment.

> I'm also curious if how we defined llvm.dbg.addr() and if it would be of any use here.

As per the link Orlando posted, the intrinsic is indeed going away, and the recommendation is to replace dbg.addr with a dbg.value + op_deref (which is what is being generated here!).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142160



More information about the llvm-commits mailing list