<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 13, 2017 at 11:25 AM, Friedman, Eli 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"><span class="">On 11/10/2017 7:54 PM, Chandler Carruth via llvm-dev wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Trying to sum-up the approaches that have been discussed, numbered in the order I saw them:<br>
<br>
1) Mangle internal names to avoid collisions.<br>
<br>
2) Only optimize library functions when they have external linkage.<br>
<br>
3) Switch optimizations to do cloning rather than mutating functions<br>
<br>
4) Mark all library functions declared in system headers with some attribute and key optimizations on this<br>
<br>
<br>
#1 doesn't seem to have much appeal.<br>
#3 is interesting and likely a good thing to do but not really sufficient to fix the root issue.<br>
#4, especially in the mode w here these attributes actually carry the semantics allowing the name-based heuristics to be isolated in a more appropriate layer, seems like a very interesting long term path, but honestly not one I have the time to bring about right now. And I don't think we can wait for this to fix things.<br>
<br>
But I think we can combine some of #4 and some of #2 to get a good solution here that is practical and achievable:<br>
<br>
- Recognize external library functions, much like we already do, but restrict it to external functions.<br>
- Recognize internal functions *with a builtin attribute* much like we do external library functions.<br>
- Teach internalize to add the builtin attribute as it changes linkage.<br>
<br>
One example of what I *really* want from this even in LTO which motivates the change to internalize: things like 'readonly' where some spec lets us optimize callers with this even if the implementation actually writes to memory. Consider building with -fno-math-errno and LTOing a libc that does actually set errno in its implementation.<br>
</blockquote>
<br></span>
If we're LTO'ing in an entire libc, there are certain functions which are special in weird ways, which I'm not sure we can represent properly with your suggested representation.  ISel can generate calls to C library functions (everything in RuntimeLibcalls.def, including memcpy/memset/memmove and a bunch of libm functions).  And the "noalias" attribute on malloc() depends on the fact that we can't actually see the implementation normally.  But maybe we can work on that incrementally?<br></blockquote><div><br></div><div><br></div><div>Note that there is option -fno-builtin-malloc for that, but there seems to be a bug in implementation -- with the flag, the noalias attribute is still applied which is wrong.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Also, as a side-note, -fno-math-errno isn't really a great example. The fact that we add readnone to math functions which can set errno is a bug; we just haven't fixed it because speed is more important than correctness in fast-math mode, and nobody has implemented a suitable alternative.  (It's easy to write a testcase where we miscompile because a math function clobbers the errno set by some other function.)</blockquote><div><br></div><div>Yes, it is a quality of implementation issue. If the side-effect/mod-ref representation in IR allows more fine grained control, e.g, allowing specifying the function only touches errno or otherwise side-effect free, then the impact on performance will be minimal.</div><div><br></div><div>David</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="im HOEnZb"><br>
<br>
-Eli<br>
<br>
-- <br>
Employee of Qualcomm Innovation Center, Inc.<br>
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project<br>
<br></span><div class="HOEnZb"><div class="h5">
______________________________<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" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
</div></div></blockquote></div><br></div></div>