[llvm-dev] DW_OP_implicit_pointer design/implementation in general

[David Blaikie via llvm-dev]

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>