llvm dev - Jan 2020 - DW_OP_implicit_pointer design/implementation in general

> On Jan 2, 2020, at 6:37 AM, Jeremy Morse <jeremy.morse.llvm at
gmail.com> wrote:
> 
> Hi all,
> 
> On the topic of intrinsics, right now we have two (dbg.value /
> dbg.addr) that respectively describe:
> * The "direct value" (quoting langref) of a variable, and
> * The address of where the current variable value is stored.
> Both of which map onto dwarf locations later on. My reasoning for
> wanting a new intrinsic is that implicit pointers are neither of these
> things: what is being described is an entirely new domain of
> information about the variable, i.e. what it points at. To me that's a
> major difference from a "direct value", and something to signal
at an
> early stage to any consumer wishing to interpret debug intrinsics,
> rather than having consumers interpret the DIExpression to discover
> whether this is actually the variable value or not.
As far as LLVM semantics are concerned, the implicit pointer doesn't seem to
be that much different from any other implicit values (such as constants) to me.
Why do you think that it needs to be represented differently inside of LLVM IR?

-- adrian
> The counter-argument would be that, in reality, dbg.value is used to
> represent everything about with variables and their values, any other
> debug intrinsic is likely to be dropped by optimisations, and you
> usually have to interpret the DIExpression anyway.
> 
> IMO, having a new intrinsic would be conceptually neater; that
> neatness might not have a lot of practical value though. I'm not
> familiar with LLVMs long term compatibility guarantees when it comes
> to intrinsics, so maybe it's more trouble than it's worth.
> 
> --
> Thanks,
> Jeremy

Hi,

On Wed, Jan 8, 2020 at 8:38 PM Adrian Prantl <aprantl at apple.com>
wrote:
> As far as LLVM semantics are concerned, the implicit pointer doesn't
seem to be that much different from any other implicit values (such as
constants) to me. Why do you think that it needs to be represented differently
inside of LLVM IR?
I think it's almost entirely that the first argument to dbg.value will
change from  "Always ValueAsMetadata" to "Maybe metadata, maybe
Value". I get the feeling that allowing more options here will come
out as more conditions / branching elsewhere, in a way we could try to
avoid.

However it's a mild opinion with a certain amount of hand waving; and
not one that anyone else seems to share, so I'm happy to drop that
part of the discussion.

--
Thanks,
Jeremy

On Fri, Jan 10, 2020 at 7:02 AM Jeremy Morse <jeremy.morse.llvm at
gmail.com>
wrote:
> Hi,
>
> On Wed, Jan 8, 2020 at 8:38 PM Adrian Prantl <aprantl at apple.com>
wrote:
> > As far as LLVM semantics are concerned, the implicit pointer
doesn't
> seem to be that much different from any other implicit values (such as
> constants) to me. Why do you think that it needs to be represented
> differently inside of LLVM IR?
>
> I think it's almost entirely that the first argument to dbg.value will
> change from  "Always ValueAsMetadata" to "Maybe metadata,
maybe
> Value".

What changes do you have in mind there? Are you referring to the
possibility of implicit values to refer to other variables?

I'm sort of interested in maybe not doing that - and only implementing a
more general form (what's been talked about with the LLVM_implicit_value
(or was it LLVM_explicit_value? I forget)) - and synthesizing artificial
variables in the backend rather than trying to track which variable a
pointer points to. I think this would keep the impact on optimizations
smaller & would be more general. My wager/belief/instinct is that most
cases won't be pointing to a named variable with a single level of
indirection, but to unnamed variables, multiple levels of indirection, etc.

> I get the feeling that allowing more options here will come
> out as more conditions / branching elsewhere, in a way we could try to
> avoid.
>
> However it's a mild opinion with a certain amount of hand waving; and
> not one that anyone else seems to share, so I'm happy to drop that
> part of the discussion.
>
> --
> Thanks,
> Jeremy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200110/24425686/attachment.html>