[llvm-dev] Unify debug and optimized variable locations with llvm.dbg.addr [was: DW_OP_LLVM_memory]

[Reid Kleckner via llvm-dev]

On Fri, Sep 8, 2017 at 10:32 AM, Adrian Prantl <aprantl at apple.com> wrote:

> > On Sep 7, 2017, at 2:18 PM, Reid Kleckner <rnk at google.com> wrote:
> >
> > On Thu, Sep 7, 2017 at 11:11 AM, Robinson, Paul <paul.robinson at sony.com>
> wrote:
> >> Different intrinsics sounds like a good solution to me. J
> >>
> >> So what happens with the case where a variable is registerized but
> later we decide to spill it?  Presumably we'd have a dbg.addr to point to
> the spill slot.  In past compilers I've used, spill slots were treated
> analogous to register allocation, i.e. some effort was made to minimize the
> number of spill slots and a variable might be spilled to different slots at
> different points.  If LLVM does that, then dbg.addr will have to be allowed
> to associated different addresses with the variable.  On the other hand, if
> LLVM allocates a unique memory "home" for each spilled variable, then
> dbg.addr can retain the property you suggest, that the address expression
> is always the same.
> >
> > dbg.addr is really IR only. Machine DBG_VALUE instructions can already
> represent addresses or values depending on their second argument. At this
> point, I don't see any reason to change that.
>
> If we can write a verifier to check the validity of a dbg.addr's address,
> why do we need the separate intrinsic? I guess the answer is that while
> every address must be a pointer value, not every pointer value is an
> address. Is this correct?
>

Mainly just for readability. We're encoding one bit of information: is the
result of DWARF expression on the LLVM value argument the variable's
address or value? The DW_OP_LLVM_memory proposal encodes that bit as a
special opcode in the expression. The dbg.addr proposal makes it more first
class: it's part of the IR, the intrinsic, not some possibly semantically
unimportant metadata. People seem to prefer that.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170911/0c3ee88f/attachment.html>