<div dir="ltr">In general, I think we are better off phrasing attributes as giving optimization power rather than restricting it. It allows for a naive optimization pass to avoid considering attributes at all.</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 27, 2017 at 11:15 AM, Robinson, Paul via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





<div lang="EN-US" link="blue" vlink="purple">
<div class="m_-2289522079602024581WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">+1 to what the Davids said.  This could also help address the situation that the Android keynote mentioned at last week's dev meeting: if you're building the
 implementation of the library you don't want the compiler to wave its magic wand because it knows better than you.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">--paulr<u></u><u></u></span></p>
<p class="MsoNormal"><a name="m_-2289522079602024581__MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></a></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> llvm-dev [mailto:<a href="mailto:llvm-dev-bounces@lists.llvm.org" target="_blank">llvm-dev-bounces@<wbr>lists.llvm.org</a>]
<b>On Behalf Of </b>Xinliang David Li via llvm-dev<br>
<b>Sent:</b> Friday, October 27, 2017 11:11 AM<br>
<b>To:</b> David Chisnall<br>
<b>Cc:</b> llvm-dev<br>
<b>Subject:</b> Re: [llvm-dev] RFC: We need to explicitly state that some functions are reserved by LLVM<u></u><u></u></span></p>
</div>
</div><div><div class="h5">
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">On Fri, Oct 27, 2017 at 1:50 AM, David Chisnall via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<u></u><u></u></p>
<p class="MsoNormal">This seems slightly inverted.  As I understand it, the root of the problem is that some standards, such as C, C++, and POSIX, define some functions as special and we rely on their specialness when optimising.  Unfortunately, the specialness
 is a property of the source language and, possibly, environment and not necessarily of the target.  The knowledge of which functions are special seems like it ought to belong in the front end, so a C++ compiler might tag a function called _Znwm as special,
 but to a C or Fortran front end this is just another function and shouldn’t be treated specially.<br>
<br>
Would it not be cleaner to have the front end (and any optimisations that are aware of special behaviour of functions) add metadata indicating that these functions are special? <u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Ideally many of these functions should be annotated as builtin in the system headers.  An hacky solution is for frontend to check if the declarations are from system headers to decide if metadata needs to be applied.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">David<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal" style="margin-bottom:12.0pt">If the metadata is lost, then this inhibits later optimisations but shouldn’t affect the semantics of the code (it’s always valid to treat the special functions as non-special functions) and optimisations then
 don’t need to mark them.  This would also give us a free mechanism of specifying functions that are semantically equivalent but have different spellings.<u></u><u></u></p>
</blockquote>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">David<u></u><u></u></p>
<div>
<div>
<p class="MsoNormal"><br>
> On 27 Oct 2017, at 04:14, Chandler Carruth via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
><br>
> I've gotten a fantastic bug report. Consider the LLVM IR:<br>
><br>
> target triple = "x86_64-unknown-linux-gnu"<br>
><br>
> define internal i8* @access({ i8* }* %arg, i64) {<br>
>   ret i8* undef<br>
> }<br>
><br>
> define i8* @g({ i8* }* %arg) {<br>
> bb:<br>
>   %tmp = alloca { i8* }*, align 8<br>
>   store { i8* }* %arg, { i8* }** %tmp, align 8<br>
>   br i1 undef, label %bb4, label %bb1<br>
><br>
> bb1:<br>
>   %tmp2 = load { i8* }*, { i8* }** %tmp, align 8<br>
>   %tmp3 = call i8* @access({ i8* }* %tmp2, i64 undef)<br>
>   br label %bb4<br>
><br>
> bb4:<br>
>   ret i8* undef<br>
> }<br>
><br>
> This IR, if compiled with `opt -passes='cgscc(inline,<wbr>argpromotion)' -disable-output` hits a bunch of asserts in the LazyCallGraph.<br>
><br>
> The problem here is that `argpromotion` turns a normal looking function `i8* @access({ i8* }* %arg, i64)` and turn it into a magical function `i8* @access(i8* %arg, i64)`. This latter signature is the POSIX `access` function that LLVM's `TargetLibraryInfo`
 knows magical things about.<br>
><br>
> Because *some* library functions known to `TargetLibraryInfo` can have *calls* to them introduced at arbitrary points of optimization (consider vectorized variants of math functions), the new pass manager and its graph to provide ordering over the module
 get Very Unhappy when you *introduce* a definition of a library function in the middle of the compilation pipeline.<br>
><br>
> And really, we do *not* want `argpromotion` to do this. We don't want it to turn some random function by the name of `@free` into the actual `@free` function and suddenly change how LLVM handles it.<br>
><br>
> So what do we do?<br>
><br>
> One option is to make `argpromotion` and every other pass that mutates a function's signature rename the function (or add a `nobuiltin` attribute to it). However, this seems brittle and somewhat complicated.<br>
><br>
> My proposal is that we admit that certain names of functions are reserved in LLVM's IR. For these names, in some cases *any* function with that name will be treated specially by the optimizer. We can still check the signatures when transforming code based
 on LLVM's semantic understanding of that function, but this avoids any need to check things when mutating the signature of the function.<br>
><br>
> This would require frontends to avoid emitting functions by these names unless they should have these special semantics. However, even if they do, everything should remain conservatively correct. But I'll send an email to cfe-dev suggesting that Clang start
 "mangling" internal functions that collide with target names. I think this is important as I've found a quite surprising number of cases where this happens in real code.<br>
><br>
> There is no need to auto-upgrade here, because again, LLVM's handling will remain conservatively correct.<br>
><br>
> Does this seem reasonable? If so, I'll send patches to update the LangRef with these restrictions. I'll also take a quick stab at generating some example tables of such names from the .td files used by `TargetLibraryInfo` already. These can't be authoritative
 because of the platform-specific nature of it, but should help people understand how this area works.<br>
><br>
><br>
> One alternative that seems appealing but doesn't actually help would be to make `TargetLibraryInfo` ignore internal functions. That is how the C++ spec seems to handle this for example (C library function names are reserved only when they have linkage). But
 this doesn't work well for LLVM because we want to be able to LTO an internalized C library. So I think we need the rule for LLVM function names to not rely on linkage here.<br>
><br>
><br>
> Thanks,<br>
> -Chandler<br>
><u></u><u></u></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">> ______________________________<wbr>_________________<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="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">
http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
<br>
______________________________<wbr>_________________<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="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><u></u><u></u></p>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
</div></div></div>
</div>
</div>

<br>______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div>