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

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>

> On Jan 10, 2020, at 11:36 AM, David Blaikie <dblaikie at gmail.com>
wrote:
> 
> 
> 
> 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.
The extra artificial variable also strikes me as a DWARF-ism that we don't
necessarily should model in LLVM IR.
>> 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.
If it were possible to synthesize it in AsmPrinter, would that remove the
motivation for the new intrinsic for you?

-- adrian

>> 
>> 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 Mon, Jan 13, 2020 at 9:20 AM Adrian Prantl <aprantl at apple.com>
wrote:
>
>
> > On Jan 10, 2020, at 11:36 AM, David Blaikie <dblaikie at
gmail.com> wrote:
> >
> >
> >
> > 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.
>
> The extra artificial variable also strikes me as a DWARF-ism that we
don't
> necessarily should model in LLVM IR.
>
Oh, yeah, that's certainly my intent in making this suggestion, that these
artificial variables would not be part of the LLVM IR and only generated in
the backend (& perhaps not generated at all in some conditions if/where we
decide to support an extension DW_OP that's more similar to what I'm
suggesting to use at the IR level). Thanks for describing/clarifying that
explicitly.

>
> >> 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.
>
> If it were possible to synthesize it in AsmPrinter, would that remove the
> motivation for the new intrinsic for you?
>
> -- adrian
>
>
> >>
> >> 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/20200113/70781caf/attachment.html>