<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">But, there are CPUs out there that have special instructions for doing<br>pointer manipulation.<br></blockquote><div>I am not sure I see why this is relevant to the byte type? </div><div><br></div><div>I believe that the issue is not that relevant to some specific architecture as it stems from the frontend and IR optimizations. As I say in the post, it is tied to C semantics saying that unsigned char is a universal type holder. This means that any pointer can be copied byte-per-byte without alias analysis in LLVM realising that, leading to incorrect IR. LLVM does not have such a type and uses untyped memory with integers carrying data (which as described in the post creates inconsistencies and invalidates certain LLVM optimizations).</div><div><br></div><div>Thanks,</div><div>George</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Oct 16, 2021 at 1:37 PM George Mitenkov <<a href="mailto:georgemitenk0v@gmail.com">georgemitenk0v@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi James,</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">If what you describe is correct, doesn't that imply that the opaque pointer work is a fools errand ?<br>I.e. If memory needs to be typed, surely pointers to that memory also need to be typed?</blockquote>Not at all, the issue described in the post is orthogonal to opaque pointers. The main problem that the post talks about is that LLVM does not have a type that represents a raw sequence of bits (i.e. memory). Currently, integers are used for that, which makes them carry pointers sometimes (as described in first parts of the post). This creates a problem for optimizations on integers, since we do not know that the values that we load are "pure" real integers or pointers casted to ints (and different LLVM optimizations make different assumptions about that).<div><br></div><div>So it is not about making memory "typed", but rather creating a universal type that can be used to load from memory something that carries raw data (integers and pointers) and preserves provenance. </div><div><br></div><div>Hope this helps!</div><div><br></div><div>Thanks,</div><div>George </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Oct 16, 2021 at 1:25 PM James Dutton <<a href="mailto:james.dutton@gmail.com" target="_blank">james.dutton@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
The gist post, seems to imply that one needs memory to be typed.<br>
If what you describe is correct, doesn't that imply that the opaque<br>
pointer work is a fools errand ?<br>
I.e. If memory needs to be typed, surely pointers to that memory also<br>
need to be typed?<br>
<br>
Kind Regards<br>
<br>
James<br>
<br>
<br>
On Fri, 15 Oct 2021 at 19:41, George Mitenkov via cfe-dev<br>
<<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br>
><br>
><br>
> Hi all,<br>
><br>
> In May 2021, together with Nuno Lopes and Juneyoung Lee, we proposed to add a byte type in LLVM to fix load type punning issues. Initial RFC touched some subtle aspects of LLVM IR and its semantics, and sparked a lot of questions, concerns, and discussions.<br>
><br>
> We decided to write a post that would summarise the thread and the complicated topic:<br>
><br>
> <a href="https://gist.github.com/georgemitenkov/3def898b8845c2cc161bd216cbbdb81f" rel="noreferrer" target="_blank">https://gist.github.com/georgemitenkov/3def898b8845c2cc161bd216cbbdb81f</a><br>
><br>
> We hope that our post clarifies initial concerns raised on the mailing list. As always, any questions, suggestions and advice are welcome!<br>
><br>
> Thanks,<br>
> George<br>
> _______________________________________________<br>
> cfe-dev mailing list<br>
> <a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div>
</blockquote></div>