[llvm-dev] [RFC] Introducing the opaque pointer type

[James Y Knight via llvm-dev]

On Tue, May 4, 2021 at 2:02 AM Nicolai Hähnle via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Hi Arthur,
>
> On Tue, May 4, 2021 at 2:39 AM Arthur Eubanks via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> For background on opaque pointer types, see [1] and many other
>> patches/threads searchable with "opaque pointers".
>>
>> While there's been lots of work around making opaque pointers work, we
>> don't actually have a type like that in LLVM yet.
>> https://reviews.llvm.org/D101704 introduces the opaque pointer type
>> within LLVM so we can start playing around with the opaque pointer type and
>> see what goes wrong. Much of the patch above is based on TNorthover's
>> branch from a couple years ago [2].
>>
>> The opaque pointer type is essentially just a PointerType with a null
>> pointee type. Calling getElementType() on an opaque pointer asserts.
>>
>> Since the bitcode representation for non-opaque pointers contains the
>> pointee type, we need a new bitcode type code for opaque pointers, which
>> only contains the address space.
>>
>> For the textual IR representation, the current proposal is to represent
>> an opaque pointer type with "ptr" with an optional "addrspace(N)". This
>> seems consistent with existing uses of "addrspace(N)" and "ptr" seems right.
>> There are a couple alternatives. TNorthover's version uses "pN" where "N"
>> is the address space, so most pointers would be "p0", and a pointer in
>> address space #5 would be "p5". I initially attempted something like
>> "ptr(N)", but the spelling is slightly ambiguous with function types. We
>> could also simply use a void pointer, which LLVM currently does not allow
>> [3].
>>
>
> Thank you for doing this, and the approach seems largely good to me,
> except for one important point: We've been moving steadily towards making
> addrspace 0 be non-special for a long time now, so I *strongly* prefer a
> spelling that always has an address space. I don't care too much about the
> exact spelling, pN and ptr(N) both seem fine to me assuming technical
> issues can be sorted out. pN has the benefit of already being used in
> codegen contexts, so count that as a *mild* preference for that spelling.
>

There are many other places in the textual IR where we use the
"addrspace(N)" syntax -- and AFAIK they all default to 0 right now. So my
first inclination would be to agree with Arthur that it's a shame to have
this syntax diverge from that. But -- do you have plans to change the
behavior of those other contexts in the future?

Cheers,
> Nicolai
>
>
>> Feel free to bikeshed.
>>
>> [1]: https://lists.llvm.org/pipermail/llvm-dev/2015-February/081822.html
>> [2]: https://lists.llvm.org/pipermail/llvm-dev/2019-December/137684.html
>> [3]: https://llvm.org/docs/LangRef.html#pointer-type
>> _______________________________________________
>> 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.
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210504/958f28d6/attachment.html>