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

[Nicolai Hähnle via llvm-dev]

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.