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

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170907/86c6626b/attachment.html>

If DBG_VALUE can distinguish then no problem.  Thanks for your patience!
--paulr

From: Reid Kleckner [mailto:rnk at google.com]
Sent: Thursday, September 07, 2017 2:18 PM
To: Robinson, Paul
Cc: llvm-dev; David Blaikie; Adrian Prantl; Alex Bradbury; Chandler Carruth
Subject: Re: Unify debug and optimized variable locations with llvm.dbg.addr
[was: DW_OP_LLVM_memory]

On Thu, Sep 7, 2017 at 11:11 AM, Robinson, Paul <paul.robinson at
sony.com<mailto:paul.robinson at sony.com>> wrote:
Different intrinsics sounds like a good solution to me. ☺

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170907/690e55af/attachment.html>

For my understanding,

based on this:
> On Sep 7, 2017, at 2:00 PM, Reid Kleckner <rnk at google.com> wrote:
>> On Thu, Sep 7, 2017 at 12:01 PM, Adrian Prantl <aprantl at
apple.com> wrote:
>> What exactly is allowed as the first parameter of a dbg.addr? Only
allocas? Anything else?
> Any pointer value. Maybe we could allow pointer-sized integers, but that
anything else is probably indescribable. If the base pointer is in XMM0, how
would we describe that with DWARF?


and this:
> 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?

-- adrian

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>