<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple style='word-wrap:break-word'><div class=WordSection1><p class=MsoNormal>Thank you for the writeup!<o:p></o:p></p><p class=MsoNormal>I think it summarizes the problem & the solution space pretty well and clearly. Well worth a read for anyone interested in contributing to the discussion.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Nuno<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal><b>From:</b> Nicolai Hähnle<br><b>Sent:</b> 11 June 2021 06:47<br><b>Subject:</b> Re: [cfe-dev] [llvm-dev] [RFC] Introducing a byte type to LLVM<o:p></o:p></p></div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>I have written a longer article that resulted as a byproduct of thinking through the problem space of this proposal: <a href="https://nhaehnle.blogspot.com/2021/06/can-memcpy-be-implemented-in-llvm-ir.html">https://nhaehnle.blogspot.com/2021/06/can-memcpy-be-implemented-in-llvm-ir.html</a><o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>What happened is that I ended up questioning some really fundamental things, like, can we even implement memcpy? :) The answer is a qualified Yes, but I found it to be a good framework for thinking about the fundamentals of what is discussed here, so I published this in the hope that others find it useful.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>tl;dr: This discussion is ultimately all about pointer provenance. There is a gap in the expressiveness of LLVM IR when it comes to that, with surprising consequences for memcpy (and similar operations). From an aesthetics point of view, filling this gap has a lot of appeal, and the "byte" proposal points in that direction. However, I have some issues with the details of the proposal, and it is so intrusive that it needs to be justified by more than just aesthetics.<br><br>The correctness issues in the problem space can be solved by much less intrusive means. The justification for the more intrusive means would be better alias analysis, but I don't think this case has been built well enough so far. We should also consider alternatives (though I don't think there are any that are truly simple).<br><br>Apart from that, we need to be much more precise in our documentation of pointer provenance in LangRef (e.g.: what does llvm.memcpy do, exactly -- the mentioned bug 37469 could technically be a bug in the loop idiom recognizer!), and I like the idea of an `unrestrict(p)` instruction as a simpler and more evocative spelling of `inttoptr(ptrtoint(p))`.<br><br>I would also like to better understand how this interacts with the C99 "restrict" work that Jeroen pointed out. Overall, this is an important discussion to have but I feel we're only at the very beginning.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>tl;dr of the tl;dr: It's complicated :)<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Cheers,<o:p></o:p></p></div><div><p class=MsoNormal>Nicolai<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><div><p class=MsoNormal>On Thu, Jun 10, 2021 at 1:15 AM Hal Finkel via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm'><p class=MsoNormal><br>On 6/9/21 12:03, Chris Lattner wrote:<br>> On Jun 6, 2021, at 8:52 AM, Hal Finkel <<a href="mailto:hal.finkel.llvm@gmail.com" target="_blank">hal.finkel.llvm@gmail.com</a>> wrote:<br>>> I'll take this opportunity to point out that, at least historically, <br>>> the reason why a desire to optimize around ptrtoint keeps resurfacing <br>>> is because:<br>>><br>>> 1. Common optimizations introduce them into code that did not <br>>> otherwise have them (SROA, for example, see convertValue in SROA.cpp).<br>>><br>>> 2. They're generated by some of the ABI code for argument passing <br>>> (see clang/lib/CodeGen/TargetInfo.cpp).<br>>><br>>> 3. They're present in certain performance-sensitive code idioms <br>>> (see, for example, ADT/PointerIntPair.h).<br>>><br>>> It seems to me that, if there's design work to do in this area, one <br>>> should consider addressing these now-long-standing issues where we <br>>> introduce ptrtoint by replacing this mechanism with some other one.<br>>><br>> I completely agree. These all have different solutions, I’d prefer to <br>> tackle them one by one.<br>><br>> -Chris<br>><br><br>I agree, these different problems have three different solutions. Also, <br>let me add that I see three quasi-separable discussions here (accounting <br>for past discussions on the same topic):<br><br> 1. Do we have a consistency problem with how we treat pointers and <br>their provenance information? The answer here is yes (see, e.g., the GVN <br>examples from this thread).<br><br> 2. Do we need to do more than be as conservative as possible around <br>ptrtoint/inttoptr usages? This is relevant because trying to be clever <br>here is often where inconsistencies around our pointer semantics are <br>exposed, although it's not always the case that problems involve <br>inttoptr. Addressing the points I raised above will lessen the <br>motivation to be more aggressive here (although, in itself, that will <br>not fix the semantic inconsistencies around pointers).<br><br> 3. Does introducing a byte type help resolve the semantic issues <br>around pointers? I don't yet understand why this might help.<br><br>Thanks again,<br><br>Hal<br><br><br>_______________________________________________<br>LLVM Developers mailing list<br><a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br><a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><o:p></o:p></p></blockquote></div><p class=MsoNormal><br clear=all><br>-- <o:p></o:p></p><div><p class=MsoNormal>Lerne, wie die Welt wirklich ist,<br>aber vergiss niemals, wie sie sein sollte.<o:p></o:p></p></div></div></div></body></html>