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

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210504/104ca903/attachment.html>

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>

On 5/3/21 11:01 PM, Nicolai Hähnle via llvm-dev wrote:
> Hi Arthur,
> 
> On Tue, May 4, 2021 at 2:39 AM Arthur Eubanks via llvm-dev <llvm-dev at
lists.llvm.org <mailto: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 <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.
> 
I think requiring an address space would be too confusing for a majority of use
cases.  Would it help if instead of defaulting to 0, the default address space
was target dependent?

- Tom
> Cheers,
> Nicolai
> 
>     Feel free to bikeshed.
> 
>     [1]:
https://lists.llvm.org/pipermail/llvm-dev/2015-February/081822.html
<https://lists.llvm.org/pipermail/llvm-dev/2015-February/081822.html>
>     [2]:
https://lists.llvm.org/pipermail/llvm-dev/2019-December/137684.html
<https://lists.llvm.org/pipermail/llvm-dev/2019-December/137684.html>
>     [3]: https://llvm.org/docs/LangRef.html#pointer-type
<https://llvm.org/docs/LangRef.html#pointer-type>
>     _______________________________________________
>     LLVM Developers mailing list
>     llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>     https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<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
>