<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">For what its worth:<o:p></o:p></p>
<p class="MsoNormal">- for the full restrict implementation, I tried to follow the specification as close as possible.<o:p></o:p></p>
<p class="MsoNormal"> Given that, refinements and tuning to the llvm-ir level behavior can be done/discussed.<o:p></o:p></p>
<p class="MsoNormal">- my interpretation of the standard is that 'an integer computation' (ak ptr2int) loses the 'based on' property. A 'int2ptr' will not bring it back (*).<o:p></o:p></p>
<p class="MsoNormal">- If you have code like:<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"> int * restrict p;<o:p></o:p></p>
<p class="MsoNormal"> int q=(int)p); // losses restrict based on<o:p></o:p></p>
<p class="MsoNormal"> p[1]=42;<o:p></o:p></p>
<p class="MsoNormal"> *(int*)(q+4) = 43; // accesses same object as p[1], but _not_ based on 'p' -> undefined behavior<o:p></o:p></p>
<p class="MsoNormal"> return p[1];<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">the final access using 'q' will result in undefined behavior.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">- (*) I made one exception to this: as llvm is (was?) sometimes introducing ptr2int /int2ptr conversions itself, I ensured that we look through these<o:p></o:p></p>
<p class="MsoNormal"> in order to track the 'based on' relationship.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">> Optimization can transform use(int2ptr(i)) inside the branch into use(int2ptr(j)) because i == j holds.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">[0] is a good read for these cases. This is a situation that the full restrict patches is not trying to fix.<o:p></o:p></p>
<p class="MsoNormal">But, the 'ptr_provenance' infrastructure it introduces is something that can be useful to tackle it.<o:p></o:p></p>
<p class="MsoNormal">As was discussed during last LLVM AA Technical call[1], this infrastructure is the next step forward to introduce<o:p></o:p></p>
<p class="MsoNormal">into the main llvm, as it will help solving these kind of issues.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Greetings,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Jeroen Dobbelaere<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">[0] pointer provenance proposal <a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2577.pdf">
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2577.pdf</a><o:p></o:p></p>
<p class="MsoNormal">[1] LLVM AA Technical Call <a href="https://docs.google.com/document/d/1ybwEKDVtIbhIhK50qYtwKsL50K-NvB6LfuBsfepBZ9Y/edit">
https://docs.google.com/document/d/1ybwEKDVtIbhIhK50qYtwKsL50K-NvB6LfuBsfepBZ9Y/edit</a>
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b>From:</b> Juneyoung Lee <juneyoung.lee@sf.snu.ac.kr> <br>
<b>Sent:</b> Friday, February 19, 2021 07:25<br>
<b>To:</b> Ryan Taylor <ryta1203@gmail.com><br>
<b>Cc:</b> Jeroen Dobbelaere <dobbel@synopsys.com>; Johannes Doerfert <johannesdoerfert@gmail.com>; llvm-dev <llvm-dev@lists.llvm.org>; Philip Reames <listmail@philipreames.com><br>
<b>Subject:</b> Re: [llvm-dev] inttoptr->add->ptrtoint capturing pointer?<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">I think inttoptr should drop noalias-ness of the input pointer because it may collide with existing optimizations.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">int i = ptr2int(p) + ofs<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">int j = ptr2int(p') + ofs'<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">if (i == j) use(int2ptr(i));<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Optimization can transform use(int2ptr(i)) inside the branch into use(int2ptr(j)) because i == j holds.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">If int2ptr preserves noalias-ness of the input pointer, this transformation becomes invalid.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">For example, if p was a normal pointer and p' was a noalias pointer, the replacement makes the program more undefined.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">In general, it is hard to detect whether an integer variable is derived from a pointer or not; imagine that i and j were complex expressions.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">In terms of correctness, it is okay for LLVM to define the inttoptr cast drop the noalias information because it makes the program more defined.<o:p></o:p></p>
<div>
<p class="MsoNormal">noalias (and restrict as well) guarantees disjointness of memory accesses by defining its violation as undefined behavior. Removing noalias is thus okay.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Fri, Feb 19, 2021 at 12:54 PM Ryan Taylor <<a href="mailto:ryta1203@gmail.com">ryta1203@gmail.com</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">
<div>
<p class="MsoNormal">Juneyoung,<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"> It seems from the spec the intention (in best practice) is to allow restrict to follow through to any pointers based on the original restrict pointer providing <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> that the new pointer is based on the original restrict pointer and only the original restrict pointer (ie, no other pointers), so on and so forth (ie propagated). <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> So in the example, the original pointer's restrict qualifier, in this case, should follow through the ptr2int->add->int2ptr to the new pointer. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"> Yes, currently (and with the new patches) this doesn't work, as int2ptr assumes capture, which prevents noalias, but should that be correct? It doesn't seem<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> like it from the spec.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Thanks.<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Thu, Feb 18, 2021 at 10:37 PM Juneyoung Lee <<a href="mailto:juneyoung.lee@sf.snu.ac.kr" target="_blank">juneyoung.lee@sf.snu.ac.kr</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">
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal">Hi,<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I think what Jeroen says is about the behavior of C programs.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">In C, an expression can be restrict-qualified, which isn't the case in LLVM IR; there is no 'i8* restrict' type or something like that.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">I guess noalias intrinsics are inserted to preserve the information when translating restrict pointers in C to IR.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">To summarize, the return value of inttoptr (which is an IR instruction) itself won't work as a restrict-qualified pointer because there is no restrict qualifier in IR.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">If it is somehow used by the noalias intrinsics, it should be able to gain the power to work as a restrict pointer.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<div>
<p class="MsoNormal">> x = (const float *)((int)x+off2))<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">> I'm not sure why this should be capturing the pointer? <o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The reason is that (int)x + off2 may accidentally point into a different object.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">A possible workaround is to use (const float*)((const char*)x+off2), which is guaranteed to preserve the provenance.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">clang-tidy has an option to detect integer-to-pointer casts to warn about possible performance degradation: <a href="https://urldefense.com/v3/__https:/clang.llvm.org/extra/clang-tidy/checks/performance-no-int-to-ptr.html__;!!A4F2R9G_pg!LKtxvZ6he7rfjJmBI-AAgN3kjUM8cqpoOQdydkds11U_1grfRzh1G03sxvK-fhYV55PmNrEq$" target="_blank">https://clang.llvm.org/extra/clang-tidy/checks/performance-no-int-to-ptr.html</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Juneyoung<o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Fri, Feb 19, 2021 at 4:00 AM Ryan Taylor <<a href="mailto:ryta1203@gmail.com" target="_blank">ryta1203@gmail.com</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">
<div>
<p class="MsoNormal">Yes, so if you have an int2ptr->add+(non-pointer)->ptr2int that should retain restrict qualifier, but you are saying it doesn't, or that the new patches won't support that, correct?<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Thanks.<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Thu, Feb 18, 2021 at 1:22 PM Jeroen Dobbelaere <<a href="mailto:Jeroen.Dobbelaere@synopsys.com" target="_blank">Jeroen.Dobbelaere@synopsys.com</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">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">> Seems like as long as the pointer is based on the restrict pointer (and no other pointer)and follows the constraints, it to is restrict qualified?<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">as long as the pointer expression is based on a restrict pointer... its accesses are associated to that restrict pointer (and assumed to not alias with other restrict pointers in
the same scope).<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Greetings,<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Jeroen Dobbelaere<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b>From:</b> Ryan Taylor <<a href="mailto:ryta1203@gmail.com" target="_blank">ryta1203@gmail.com</a>>
<br>
<b>Sent:</b> Thursday, February 18, 2021 19:11<br>
<b>To:</b> Jeroen Dobbelaere <<a href="mailto:dobbel@synopsys.com" target="_blank">dobbel@synopsys.com</a>><br>
<b>Cc:</b> Johannes Doerfert <<a href="mailto:johannesdoerfert@gmail.com" target="_blank">johannesdoerfert@gmail.com</a>>; llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>; Juneyoung Lee <<a href="mailto:juneyoung.lee@sf.snu.ac.kr" target="_blank">juneyoung.lee@sf.snu.ac.kr</a>>;
Philip Reames <<a href="mailto:listmail@philipreames.com" target="_blank">listmail@philipreames.com</a>><br>
<b>Subject:</b> Re: [llvm-dev] inttoptr->add->ptrtoint capturing pointer?<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Ok, just clarifying. <o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Am I interrupting 6.7.3.1.4 incorrectly? <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Seems like as long as the pointer is based on the restrict pointer (and no other pointer)and follows the constraints, it to is restrict qualified?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> During each execution of B, let L be any lvalue that has &L based on P. If L is used to access the value of the object X that it designates, and X is also modified (by any means),
then the following requirements apply: T shall not be const-qualified. Every other lvalue used to access the value of X shall also have its address based on P. Every access that modifies X shall be considered also to modify P, for the purposes of this subclause.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Thanks. <o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
</div>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">On Thu, Feb 18, 2021 at 12:59 PM Jeroen Dobbelaere <<a href="mailto:Jeroen.Dobbelaere@synopsys.com" target="_blank">Jeroen.Dobbelaere@synopsys.com</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-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">> So if some restrict pointer 'x' is casted to int, adds 1, then casted back to pointer, it nullifies the restrict qualifier, despite the results having no other uses?<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">yes.<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">int * restrict x = ...;<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">bad usage:<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> *(int*)((int)x + 1) = 42;<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">valid usage:<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> x = (int*)((int)x + 1);<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> *x = 42;<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Greetings,<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Jeroen Dobbelaere<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b>From:</b> Ryan Taylor <<a href="mailto:ryta1203@gmail.com" target="_blank">ryta1203@gmail.com</a>>
<br>
<b>Sent:</b> Thursday, February 18, 2021 18:51<br>
<b>To:</b> Jeroen Dobbelaere <<a href="mailto:dobbel@synopsys.com" target="_blank">dobbel@synopsys.com</a>><br>
<b>Cc:</b> Johannes Doerfert <<a href="mailto:johannesdoerfert@gmail.com" target="_blank">johannesdoerfert@gmail.com</a>>; llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>; Juneyoung Lee <<a href="mailto:juneyoung.lee@sf.snu.ac.kr" target="_blank">juneyoung.lee@sf.snu.ac.kr</a>>;
Philip Reames <<a href="mailto:listmail@philipreames.com" target="_blank">listmail@philipreames.com</a>><br>
<b>Subject:</b> Re: [llvm-dev] inttoptr->add->ptrtoint capturing pointer?<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">So if some restrict pointer 'x' is casted to int, adds 1, then casted back to pointer, it nullifies the restrict qualifier, despite the results having no other uses?<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Thanks.<o:p></o:p></p>
</div>
</div>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">On Thu, Feb 18, 2021 at 12:41 PM Jeroen Dobbelaere <<a href="mailto:Jeroen.Dobbelaere@synopsys.com" target="_blank">Jeroen.Dobbelaere@synopsys.com</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-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">> How will inttoptr work with the new restrict patches? Certainly the int2ptr capturing shouldn't nullify the restrict qualifier.<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">The full restrict patches see through 'inttoptr(ptrtoint( x ) )', Besides that, the analysis stops at 'ptr2int(x)' and 'anything can happen'.<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Because of this, all other 'inttoptr' usages will never introduce a restrict provenance.<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">(aka, a restrict pointer converted to an int + some computations and then converted back to a pointer will normally not retain the 'restrictness' and that can trigger undefined
behavior)<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Greetings,<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Jeroen Dobbelaere<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b>From:</b> Ryan Taylor <<a href="mailto:ryta1203@gmail.com" target="_blank">ryta1203@gmail.com</a>>
<br>
<b>Sent:</b> Thursday, February 18, 2021 18:31<br>
<b>To:</b> Johannes Doerfert <<a href="mailto:johannesdoerfert@gmail.com" target="_blank">johannesdoerfert@gmail.com</a>><br>
<b>Cc:</b> llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>; Jeroen Dobbelaere <<a href="mailto:dobbel@synopsys.com" target="_blank">dobbel@synopsys.com</a>>; Juneyoung Lee <<a href="mailto:juneyoung.lee@sf.snu.ac.kr" target="_blank">juneyoung.lee@sf.snu.ac.kr</a>>;
Philip Reames <<a href="mailto:listmail@philipreames.com" target="_blank">listmail@philipreames.com</a>><br>
<b>Subject:</b> Re: [llvm-dev] inttoptr->add->ptrtoint capturing pointer?<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Juneyoung said he hadn't started working on it yet, so I'm going to take a look at it also.<o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">How will inttoptr work with the new restrict patches? Certainly the int2ptr capturing shouldn't nullify the restrict qualifier.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Thanks.<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">On Thu, Feb 18, 2021 at 12:04 PM Johannes Doerfert <<a href="mailto:johannesdoerfert@gmail.com" target="_blank">johannesdoerfert@gmail.com</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-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">I think you are working with a custom llvm here but I will<br>
make a few general statements that might help:<br>
<br>
- The noalias intrinsic as you've shown it captures, unfortunately.<br>
We don't have the `nocapture_maybe_returned` attribute in IR yet that <br>
the Attributor uses for these situations,<br>
IIRC, Juneyoung is working on making it an LLVM-IR enum attribute <br>
already.<br>
<br>
- int2ptr is assumed to capture in basically every analysis I've seen. <br>
It doesn't intrinsically but it is really<br>
hard to get it right. That said, we could allow *very* special <br>
patterns but I would argue those should be recognized<br>
in instcombine and replaced there.<br>
<br>
- Philip and I are working to define capture better for the lang ref, we <br>
might want to include some examples and<br>
rational around int2ptr when we have a coherent model.<br>
<br>
I've CC'ed people that might correct me or augment my answer, hope this <br>
helps :)<br>
<br>
~ Johannes<br>
<br>
<br>
On 2/18/21 9:17 AM, Ryan Taylor via llvm-dev wrote:<br>
> I have an example:<br>
><br>
> foo(float * restrict y, int off1, int off2) {<br>
> float * restrict x;<br>
> for (..) {<br>
> for (..) {<br>
> x = y+off1;<br>
> }<br>
> x = (const float *)((int)x+off2))<br>
><br>
> I'm not sure why this should be capturing the pointer?<br>
><br>
> For instance, looking at scoped noalias dbg info:<br>
><br>
> SNA: Capture check for B/CSB UO: %54 = inttoptr i32 %add83 to float*,<br>
> !dbg !101<br>
> SNA: Pointer %1 = call float* @llvm.noalias.p0_float(float* %0, metadata<br>
> !38), !dbg !41 might be captured!<br>
><br>
> Is this implying that the noalias intrinsic might be capturing the pointer?<br>
> It doesn't look like "noalias" intrinsic has NoCapture property on the<br>
> pointer:<br>
><br>
> def int_noalias : Intrinsic<[llvm_anyptr_ty],<br>
> [LLVMMatchType<0>, llvm_metadata_ty],<br>
> [IntrArgMemOnly, Returned<0>]>;<br>
><br>
> It should though right? From the definition of capture it is returning the<br>
> pointer; however, we know nothing is happening here.<br>
><br>
> I'm on llvm 10 with Hal's restrict patches.<br>
><br>
> Thanks.<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://urldefense.com/v3/__https:/lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev__;!!A4F2R9G_pg!Pm5BQtdh_gU6pe-WvhApIs2FOjI1V7vJDj6H93m0sNUItsa5T6CbzW5JL1cixruSF_kY7ywW$" target="_blank">
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><o:p></o:p></p>
</blockquote>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</blockquote>
</div>
<p class="MsoNormal"><br clear="all">
<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">-- <o:p></o:p></p>
<div>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal"><span style="font-size:7.5pt">Juneyoung Lee</span><o:p></o:p></p>
<div>
<p class="MsoNormal"><span style="font-size:7.5pt">Software Foundation Lab, Seoul National University</span><o:p></o:p></p>
</div>
</div>
</div>
</blockquote>
</div>
</blockquote>
</div>
<p class="MsoNormal"><br clear="all">
<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">-- <o:p></o:p></p>
<div>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal"><span style="font-size:7.5pt">Juneyoung Lee</span><o:p></o:p></p>
<div>
<p class="MsoNormal"><span style="font-size:7.5pt">Software Foundation Lab, Seoul National University</span><o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</body>
</html>