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

[Arthur Eubanks via llvm-dev]

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].
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210503/419ce297/attachment.html>