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

I agree. I think it would be a mistake to add an unnecessary difference vs.
typed pointers along some other axis (address space, or otherwise). Opaque
pointers have enough of their own challenges to solve.
> On 2021 May  10, at 15:28, Arthur Eubanks via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> If there's a larger effort to make address spaces then I'd be happy
to change the representation since mass updating tests once is better than
twice, but I'm worried that this may start becoming intertwined with more
address space work, and the opaque pointers project has gone on long enough
(like many other LLVM projects).
> 
> And of course, there's always time before we do mass test updates to
easily change the textual representation.
> 
> On Fri, May 7, 2021 at 11:27 AM David Blaikie <dblaikie at gmail.com
<mailto:dblaikie at gmail.com>> wrote:
> On Fri, May 7, 2021 at 11:20 AM Arthur Eubanks via llvm-dev
> <llvm-dev at lists.llvm.org <mailto: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 <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?
> >
> >
> > 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
> _______________________________________________
> 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/20210510/29d9c519/attachment.html>

I am very much beginner in opaque pointers but I am also minimalist too in
a sense entities shouldnt be multiplied but rather divided where applicable.

Can someone point me to article(s) describing what problems opaque pointers
solve that cant be solved with forward declaractions and typed pointers etc?

My first gutfeeling was when learning on idea of opaque pointers, theyre
not much more than void* with all its issues from static analysis, compiler
design, code readability, code quality, code security perspective. Can
someone correct a newbie? Very open to change my mind.

-Pawel

wt., 11.05.2021, 02:35 użytkownik Duncan P. N. Exon Smith via llvm-dev <
llvm-dev at lists.llvm.org> napisał:
> I agree. I think it would be a mistake to add an unnecessary difference
> vs. typed pointers along some other axis (address space, or
> otherwise). Opaque pointers have enough of their own challenges to solve.
>
> On 2021 May  10, at 15:28, Arthur Eubanks via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> If there's a larger effort to make address spaces then I'd be happy
to
> change the representation since mass updating tests once is better than
> twice, but I'm worried that this may start becoming intertwined with
more
> address space work, and the opaque pointers project has gone on long enough
> (like many other LLVM projects).
>
> And of course, there's always time before we do mass test updates to
> easily change the textual representation.
>
> On Fri, May 7, 2021 at 11:27 AM David Blaikie <dblaikie at gmail.com>
wrote:
>
>> 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
>>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
> _______________________________________________
> 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/20210511/d3162c6c/attachment.html>