<div dir="auto">Ok cool. If that makes llvm better cool with me. Just dont spread it to lang spec. One void* issue in complang spec is more than enough trouble from perspective of dude working on static analysis and other mentioned topics.<div dir="auto"><br></div><div dir="auto">-Pawel</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">wt., 11.05.2021, 09:20 użytkownik David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> napisał:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr">On Mon, May 10, 2021 at 11:59 PM pawel k. via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">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.<div dir="auto"><br></div><div dir="auto">Can someone point me to article(s) describing what problems opaque pointers solve that cant be solved with forward declaractions and typed pointers etc?</div><div dir="auto"><br></div><div dir="auto">My first gutfeeling was when learning on idea of opaque pointers, theyre not much more than void*</div></div></blockquote><div><br>Yep, that's basically what they are. Though this is only relative to the IR design, not source language design.<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="auto"> 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.</div></div></blockquote><div><br>LLVM doesn't provide any guarantees about pointer types (unlike, say, C++ that has type based aliasing guarantees about pointers - if you have an int* you know it can't hold the same value as a float* in C++, but this property isn't true in LLVM IR (this information can be carried separately in type based alias analysis metadata - but it's not inherent in the LLVM IR of pointers themselves)) - so the type information provides limited value (somewhat useful for frontends generating IR to be able to have some intended type information carried around in the IR as it's being constructed) and inhibits optimizations - converting between pointer types involves instructions (geps or bitcasts) - instructions that optimizations have to know to skip over/look through. <br><br>So instead, we're moving to a model where pointers don't have a type (since it's not informative to optimizations anyway) - and operations carry type information (instead of "load from this int pointer" it'll be "load an integer from this opaque pointer").<br><br>If you look at the LLVM IR today, you'll see these explicit types on operations (eg: the load instruction has an explicit type parameter to it, which currently looks redundant with the type of the pointer parameter that's passed to the load instruction - but in the future that pointer parameter won't carry any pointee type information and the load will rely entirely on the explicit type parameter it has).<br><br>- Dave <br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="auto"><br></div><div dir="auto">-Pawel</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">wt., 11.05.2021, 02:35 użytkownik Duncan P. N. Exon Smith via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a>> napisał:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>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.<div><div><br><blockquote type="cite"><div>On 2021 May  10, at 15:28, Arthur Eubanks via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" rel="noreferrer noreferrer" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:</div><br><div><div dir="ltr">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).<div><br></div><div>And of course, there's always time before we do mass test updates to easily change the textual representation.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 7, 2021 at 11:27 AM David Blaikie <<a href="mailto:dblaikie@gmail.com" rel="noreferrer noreferrer" target="_blank">dblaikie@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, May 7, 2021 at 11:20 AM Arthur Eubanks via llvm-dev<br>
<<a href="mailto:llvm-dev@lists.llvm.org" rel="noreferrer noreferrer" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
><br>
><br>
><br>
> On Fri, May 7, 2021 at 8:40 AM David Chisnall via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" rel="noreferrer noreferrer" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
>><br>
>> On 04/05/2021 19:32, Tom Stellard via llvm-dev wrote:<br>
>> > I think requiring an address space would be too confusing for a majority<br>
>> > of use<br>
>> > cases.  Would it help if instead of defaulting to 0, the default address<br>
>> > space<br>
>> > was target dependent?<br>
>><br>
>> For CHERI targets, the default address space is ABI dependent: AS0 is a<br>
>> 64-bit integer that's relative to the default data capability, AS200 is<br>
>> a 128-bit capability (on 64-bit platforms).  It can also differ between<br>
>> code, heap, and stack.<br>
>><br>
>> If this is purely a syntactic thing in the text serialisation, would it<br>
>> be possible to put something in the DataLayout that is ignored by<br>
>> everything except the pretty-printer / parser?<br>
><br>
> Could you give an example?<br>
><br>
><br>
> 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.<br>
<br>
+1 to this - pointers already carry their address space with explicit<br>
syntax and I think it's OK to do that for this transition. Though I<br>
wouldn't be opposed to a change in the future to roll it into the<br>
pointer type name if that seems suitable.<br>
<br>
- Dave<br>
</blockquote></div>
_______________________________________________<br>LLVM Developers mailing list<br><a href="mailto:llvm-dev@lists.llvm.org" rel="noreferrer noreferrer" target="_blank">llvm-dev@lists.llvm.org</a><br><a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br></div></blockquote></div><br></div></div>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" rel="noreferrer noreferrer" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer noreferrer noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div>
</blockquote></div>