<html><body bgcolor="#FFFFFF"><p><font size="2">Hi,</font><br><br><font size="2">Very appreciate for all your input.</font><br><br><font size="2">it is indeed a very aggressive optimization and it is not safe in many cases. But it should be helpful to tune application's performance if it is safe.</font><br><br><font size="2">I think if we want to support it, we must:</font><br><font size="2">1: only let compiler user turn it on by explicitly specifying -fforce-restrict-ptr-args, otherwise it is always off.</font><br><font size="2">2: emit a warning message to remind this opt will change program semantics if users turn it on.</font><br><font size="2">3: restrict its application to C/C++.</font><br><br><font size="2">Any ideas?</font><br><br><font size="2">Thanks.</font><br><br><font size="2">BRS//</font><br><font size="2">Chen Zheng</font><br><font size="2">Power Compiler Backend Developer</font><br><br><br><img width="16" height="16" src="cid:1__=C7BB0917DF9E23C68f9e8a93df938690918cC7B@" border="0" alt="Inactive hide details for Troy Johnson ---2019/01/16 02:32:22 AM---Restrict is supported by Clang for C++ via __restrict__, so "><font size="2" color="#424282">Troy Johnson ---2019/01/16 02:32:22 AM---Restrict is supported by Clang for C++ via __restrict__, so it seems strange to block using this pro</font><br><br><font size="2" color="#5F5F5F">From:        </font><font size="2">Troy Johnson <troyj@cray.com></font><br><font size="2" color="#5F5F5F">To:        </font><font size="2">"Finkel, Hal J." <hfinkel@anl.gov>, Zheng CZ Chen <czhengsz@cn.ibm.com></font><br><font size="2" color="#5F5F5F">Cc:        </font><font size="2">"llvm-dev@lists.llvm.org" <llvm-dev@lists.llvm.org></font><br><font size="2" color="#5F5F5F">Date:        </font><font size="2">2019/01/16 02:32 AM</font><br><font size="2" color="#5F5F5F">Subject:        </font><font size="2">RE: [llvm-dev] Aggressive optimization opportunity</font><br><hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br><br><br><font color="#1F497D">Restrict is supported by Clang for C++ via __restrict__, so it seems strange to block using this proposed option for C++.</font><br><font color="#1F497D"> </font><br><font color="#1F497D">That said, this kind of option can be dangerous and should come with a suitable warning.  We’ve had a similar option and in practice it’s been used to hunt for performance gains (i.e., turn it on and see what happens), but just because the code runs faster and produces the correct result with the option enabled doesn’t mean it is safe in all cases.  And if it crashes or gives you wrong answers, you still don’t know which pointer had the alias that caused that problem.  Either way, you still need to inspect all of the pointers and prove to yourself it is safe and at that point you might as well add restrict manually.</font><br><font color="#1F497D"> </font><br><font color="#1F497D">-Troy</font><br><font color="#1F497D"> </font><br><b>From:</b> llvm-dev <llvm-dev-bounces@lists.llvm.org> <b>On Behalf Of </b>Finkel, Hal J. via llvm-dev<b><br>Sent:</b> Tuesday, January 15, 2019 9:57 AM<b><br>To:</b> Zheng CZ Chen <czhengsz@cn.ibm.com>; llvm-dev@lists.llvm.org<b><br>Subject:</b> Re: [llvm-dev] Aggressive optimization opportunity<br><font face="Times New Roman"> </font><p><font face="Times New Roman"> </font><br><font face="Times New Roman">On 1/15/19 6:07 AM, Zheng CZ Chen via llvm-dev wrote:</font><ul><ul><font size="2" face="Times New Roman">Hi,</font><font face="Times New Roman"><br></font><font size="2" face="Times New Roman"><br>There are some compilers with a aggressive optimization which restricts function pointer parameters. Let's say opt restrict_args. When restrict_args is turned on, compiler will treat all function pointer parameters as restrict one.</font></ul></ul><font face="Times New Roman"> </font><p><font face="Times New Roman">I certainly understand the use case, in a general sense. In my experience, these options are used with (fairly old) pre-C99 code bases (and specifically C, not C++), which follow something akin to a one-function-per-source-file model and which can't be modified (e.g., for licensing reasons). Using these options are certainly considered bad practice, and they only apply to certain legacy code bases. Does this match your experience and expected usage?</font><p><font face="Times New Roman">In an engineering sense, this seems like a trivial feature to support. I don't object to supporting it, but if we do, we probably want to:</font><p><font face="Times New Roman"> 1. Restrict it's application to C (e.g., it should be an error to use with C++, OpenCL, CUDA, and any other languages that Clang supports).</font><p><font face="Times New Roman"> 2. When used with C99 or later language standards, the use of this flag generates a warning on each function definition with a fixit hint showing where the restrict keyword should be placed (we can then, optionally of course, use these fixits to automatically upgrade code where possible using our corresponding infrastructure). This warning should have a separate flag, and is disabled by default for pre-C99 standard modes, and enabled by default otherwise, but can be toggled independently.</font><p><font face="Times New Roman"> -Hal</font><ul><ul><i><font size="2" face="Times New Roman"><br>int foo(int * a) </font></i><font size="2" face="Times New Roman">+ restrict_args opt </font><font face="Times New Roman"><br></font><font size="2" face="Times New Roman"><br>equals to:</font><font face="Times New Roman"><br></font><i><font size="2" face="Times New Roman"><br>int foo(int * restrict a)</font></i><font face="Times New Roman"><br><br></font><font size="2" face="Times New Roman"><br>Here is a complete example:<br>source code:<br>extern int num;</font><i><font size="2" face="Times New Roman"><br>int foo(int * a)<br>{<br>(*a) = 10;<br>num++;<br>(*a)++;</font></i><font face="Times New Roman"><br></font><i><font size="2" face="Times New Roman"><br>return *a; <br>}</font></i><font face="Times New Roman"><br></font><font size="2" face="Times New Roman"><br>Using IBM xlc compiler with option -qrestrict at -O2, we get result:</font><font face="Times New Roman"><br></font><font size="2" face="Times New Roman"><br>0000000000000000 <foo>:<br>0: 00 00 4c 3c addis r2,r12,0<br>4: 00 00 42 38 addi r2,r2,0<br>8: 00 00 a2 3c addis r5,r2,0<br>c: 00 00 a5 e8 ld r5,0(r5)<br>10: 0b 00 00 38 li r0,11<br>14: 00 00 03 90 stw r0,0(r3)<br>18: 00 00 85 80 lwz r4,0(r5)</font><b><font size="2" face="Times New Roman"><br>1c: 0b 00 60 38 li r3,11 ------>since we confirm num will not change the content where pointer to, compiler can directly return 11.</font></b><font size="2" face="Times New Roman"><br>20: 01 00 04 38 addi r0,r4,1<br>24: 00 00 05 90 stw r0,0(r5)<br>28: 20 00 80 4e blr</font><font face="Times New Roman"><br></font><font size="2" face="Times New Roman"><br>Seems clang does not have such optimization. And I don't find similar option in gcc either.</font><font face="Times New Roman"><br></font><font size="2" face="Times New Roman"><br>Is it possible to add this optimization into clang?</font><font face="Times New Roman"><br></font><font size="2" face="Times New Roman"><br>Thanks.</font><font face="Times New Roman"><br></font><font size="2" face="Times New Roman"><br>BRS//<br>Chen Zheng<br>Power Compiler Backend Developer</font><br><font face="Times New Roman"><br></font><br><font size="2" face="Courier New">_______________________________________________</font><br><font size="2" face="Courier New">LLVM Developers mailing list</font><br><a href="mailto:llvm-dev@lists.llvm.org"><u><font size="2" color="#0000FF" face="Courier New">llvm-dev@lists.llvm.org</font></u></a><br><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev"><u><font size="2" color="#0000FF" face="Courier New">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</font></u></a></ul></ul><font size="2" face="Courier New">-- </font><br><font size="2" face="Courier New">Hal Finkel</font><br><font size="2" face="Courier New">Lead, Compiler Technology and Programming Languages</font><br><font size="2" face="Courier New">Leadership Computing Facility</font><br><font size="2" face="Courier New">Argonne National Laboratory</font><br><br><BR>
</body></html>