llvm dev - Dec 2019 - RFC: Opaque pointer status and future direction

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

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.

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>

Re-upping this thread from almost two months ago...

As I expected, one new use of a deprecated IRBuilder::CreateCall
method has cropped up, and probably more of the CreateLoad variety. To
put an end to this whack-a-mole, I suggested back then to mark those
methods deprecated for real with an attribute.
https://reviews.llvm.org/D74676 (+ parent revisions on the stack) does
this for CreateCall, which is the least painful one to address.

Cheers,
Nicolai

On Tue, Dec 24, 2019 at 12:16 AM David Blaikie via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
>
>
> 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.
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


-- 
Lerne, wie die Welt wirklich ist,
aber vergiss niemals, wie sie sein sollte.