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

[Tim Northover via llvm-dev]

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