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

On Fri, May 7, 2021 at 8:40 AM David Chisnall via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On 04/05/2021 19:32, Tom Stellard via llvm-dev wrote:
> > 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?
>
> For CHERI targets, the default address space is ABI dependent: AS0 is a
> 64-bit integer that's relative to the default data capability, AS200 is
> a 128-bit capability (on 64-bit platforms).  It can also differ between
> code, heap, and stack.
>
> If this is purely a syntactic thing in the text serialisation, would it
> be possible to put something in the DataLayout that is ignored by
> everything except the pretty-printer / parser?
>
Could you give an example?


Also, perhaps we should separate the opaque pointer types transition from
any changes to address spaces. Currently the proposal is basically
unchanged from the current status quo in terms of pointer address spaces.
We definitely should have a "default" pointer type in some shape or
form
which is represented by "ptr", or else writing IR tests is too
cumbersome.
Currently that means AS0, but we can change that in the future if we want
independently of opaque pointers.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210507/a3a56fd6/attachment.html>

On Fri, May 7, 2021 at 11:20 AM Arthur Eubanks via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
>
>
> On Fri, May 7, 2021 at 8:40 AM David Chisnall via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
>>
>> On 04/05/2021 19:32, Tom Stellard via llvm-dev wrote:
>> > 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?
>>
>> For CHERI targets, the default address space is ABI dependent: AS0 is a
>> 64-bit integer that's relative to the default data capability,
AS200 is
>> a 128-bit capability (on 64-bit platforms).  It can also differ between
>> code, heap, and stack.
>>
>> If this is purely a syntactic thing in the text serialisation, would it
>> be possible to put something in the DataLayout that is ignored by
>> everything except the pretty-printer / parser?
>
> Could you give an example?
>
>
> Also, perhaps we should separate the opaque pointer types transition from
any changes to address spaces. Currently the proposal is basically unchanged
from the current status quo in terms of pointer address spaces. We definitely
should have a "default" pointer type in some shape or form which is
represented by "ptr", or else writing IR tests is too cumbersome.
Currently that means AS0, but we can change that in the future if we want
independently of opaque pointers.
+1 to this - pointers already carry their address space with explicit
syntax and I think it's OK to do that for this transition. Though I
wouldn't be opposed to a change in the future to roll it into the
pointer type name if that seems suitable.

- Dave

On 07/05/2021 19:20, Arthur Eubanks wrote:
> 
> 
> On Fri, May 7, 2021 at 8:40 AM David Chisnall via llvm-dev 
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>> wrote:
> 
>     On 04/05/2021 19:32, Tom Stellard via llvm-dev wrote:
>      > 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?
> 
>     For CHERI targets, the default address space is ABI dependent: AS0 is a
>     64-bit integer that's relative to the default data capability,
AS200 is
>     a 128-bit capability (on 64-bit platforms).  It can also differ between
>     code, heap, and stack.
> 
>     If this is purely a syntactic thing in the text serialisation, would it
>     be possible to put something in the DataLayout that is ignored by
>     everything except the pretty-printer / parser?
> 
> Could you give an example?
An example of what?
> Also, perhaps we should separate the opaque pointer types transition 
> from any changes to address spaces. Currently the proposal is basically 
> unchanged from the current status quo in terms of pointer address 
> spaces. We definitely should have a "default" pointer type in
some shape
> or form which is represented by "ptr", or else writing IR tests
is too
> cumbersome. Currently that means AS0, but we can change that in the 
> future if we want independently of opaque pointers.
I agree that doing this incrementally is probably the right thing, but I 
disagree on the tests side.  If we used a p{address space} notation then 
writing p0 is less to type than ptr, so writing tests that want AS0 is 
less effort and writing tests that want another address space is even 
less effort than writing `ptr addrspace(42)`.

David