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

[David Blaikie via llvm-dev]

On Mon, Sep 11, 2017 at 12:35 PM Reid Kleckner <rnk at google.com> wrote:

> 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.
>

People do? I'd actually lean the other way myself (closer to DWARF, fewer
first class constructs in the IR/more orthogonality, etc) - FWIW, or in
case my other rambling emails were confusing. (well, maybe the intermediate
state/mismatch between LLVM IR and DWARF is enough that it can't be close
enough to DWARF to be sensible/tidy, so taking it further away as you're
suggesting here might be better).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170911/377170d1/attachment.html>