[llvm-dev] RFC: Opaque pointer status and future direction

[David Blaikie via llvm-dev]

On Thu, Dec 19, 2019 at 11:27 AM Tim Northover <t.p.northover at gmail.com>
wrote:

> >> So at a high level I think we should put the serialization and
> Instruction
> >> changes in sooner rather than later, giving us a largely
> undocumented[2] dialect
> >> of IR with opaque pointers that we can write tests against to upstream
> the rest
> >> of what I've done (and others can use to continue work in parallel if
> they're
> >> inclined).
> >
> > My, admittedly rather vague, plan was to change the API down to the
> point where there was only a primitive for "propagating pointee type from
> one place to another" but without the ability to query it otherwise - well,
> with a deprecated way to query it that we could chase down calls to as the
> main migration. Once we got to zero "getElementType" callers we could
> figure out the actual IR migration piece.
> >
> > Do you think that wouldn't be viable & that introducing the new opaque
> pointer type sooner would be better/more viable?
>
> I think it'd be viable, but would turn many of the patches into NFC
> with no way to test them.


Hmm, I get where you're coming from & would hope they'd sort of be NFC -
but yeah, if we made these changes with an opaque pointer type available,
we could write tests demonstrating the support for opaque pointers by
writing test cases with mismatched pointers... except they wouldn't be
mismatched anyway because there'd be no type. So I guess at best we could
demonstrate a new optimization available with the opaque pointers that
couldn't be expressed with typed pointers.


> I'm quite happy to do that for strictly
> obvious changes, but I get a bit more nervous when we get to larger
> scale refactorings. I'd like to be able to do more than just hope
> people don't regress to getElementPtr, ideally.
>

Please go ahead with whatever way you think works best - I can totally see
it both/either way.


> But I think that approach definitely pushes the IR changes from
> short/medium term to medium term at the very least, and I'll pursue
> the kind of patches you're suggesting for now. Perhaps revisit the
> question when things start getting tricky.
>
> > Is byval already fixed/changed? I may've lost track of some of these
> changes, but I knew that was next on my list. (& how was byval addressed -
> byval(<ty>) or byval(byte count)? I guess inalloca goes/should go the same
> way as byval)
>
> byval(<ty>) is in, and used by Clang now. In retrospect I should have
> done inalloca at the same time, but for some reason I decided it
> wasn't necessary. I think it'll need the same conversion, and then
> both must be made compulsory.
>
> Cheers.
>
> Tim.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191223/5af87093/attachment.html>