<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<div class="moz-cite-prefix">On 08/16/2018 03:41 PM, Troy Johnson
via llvm-dev wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CY4PR11MB13976BB248CF9935728C28FDC63E0@CY4PR11MB1397.namprd11.prod.outlook.com">
<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:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:1556087348;
mso-list-type:hybrid;
mso-list-template-ids:-1124977184 67698705 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
{mso-level-text:"%1\)";
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></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]-->
<div class="WordSection1">
<p class="MsoNormal">Concerning slide 16 of <a
href="https://llvm.org/devmtg/2017-02-04/Restrict-Qualified-Pointers-in-LLVM.pdf"
moz-do-not-send="true">
https://llvm.org/devmtg/2017-02-04/Restrict-Qualified-Pointers-in-LLVM.pdf</a><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Specifically “Currently, LLVM only supports
restrict on function arguments, although we have a way to
preserve that information if the function is inlined.”<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Is that statement still accurate?</p>
</div>
</blockquote>
<br>
Yes.<br>
<br>
<blockquote type="cite"
cite="mid:CY4PR11MB13976BB248CF9935728C28FDC63E0@CY4PR11MB1397.namprd11.prod.outlook.com">
<div class="WordSection1">
<p class="MsoNormal"> It would seem that <a
href="https://llvm.org/docs/LangRef.html#noalias-and-alias-scope-metadata"
moz-do-not-send="true">
https://llvm.org/docs/LangRef.html#noalias-and-alias-scope-metadata</a>
should be sufficiently general to honor C’s restrict qualifier
on local pointers, but it does not appear that Clang uses this
part of LLVM’s IR for that purpose today and thus local
restricts are ignored.</p>
</div>
</blockquote>
<br>
It could in some cases, and in fact that was my original thought,
but making it work well seems to require a bunch of analysis in the
frontend. The problem is that, in order to conclude that two
pointers don't alias based on restrict, you need to know that one
pointer is based on the restrict-qualified pointer and the other,
within the appropriate scope, is not. Doing this relies on data-flow
and aliasing analysis (which would need to be pretty simple in the
frontend), but also becomes pessimistic when pointers are passed to
functions (because they might be captured). Especially in C++ (where
restrict is often used as an extension), the function-call-capturing
problem can be significant because all of the overloaded operators
are function calls (and so on). When we have restrict on function
parameters we add noalias on the LLVM IR level to those parameters,
and if we later inline that function, we add this noalias metadata,
but at that point, we've already done IPO nocapture inference,
memory-to-register conversation, and have access to LLVM's AA
infrastructure.<br>
<br>
I'd proposed an llvm.noalias intrinsic in order to address this
problem (and the patches for this, including frontend patches, are
on phabricator). Originally, I had wanted to make the intrinsic
fairly transparent, such that it would have minimal interference on
other optimizations. Part of the problem is that I wanted to
intrinsic to fix itself to a particular place in the CFG in order to
be able to differentiate, as a particular design point, between
noalias pointers within one loop iteration vs. across all loop
iterations (based on whether the intrinsic was inside or outside the
loop). This means that the intrinsic had to be annotated such that
it could not be hoisted. In any case, after testing, we found
problems with the transparency of the intrinsic because, both
literally and effectively during the recursive AA-query-processing
algorithm, we could break the dependence of a pointer value on the
intrinsic from which it was originally derived. This can't happen
and have the scheme maintain correctness. Thus, we need to make it
hard for analysis to look through the intrinsic, and thus it even
has a larger impact on other optimizations. Several people have been
thinking about this problem, but I wouldn't say that we yet have a
clearly-good answer yet. Maybe we want to start with the intrinsic
and then translate it later into maetadata, for example.<br>
<br>
-Hal<br>
<br>
<blockquote type="cite"
cite="mid:CY4PR11MB13976BB248CF9935728C28FDC63E0@CY4PR11MB1397.namprd11.prod.outlook.com">
<div class="WordSection1">
<p class="MsoNormal"><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thanks,<o:p></o:p></p>
<p class="MsoNormal">Troy<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<!--'"--><br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
</body>
</html>