[llvm-dev] RFC: We need to explicitly state that some functions are reserved by LLVM

[Friedman, Eli via llvm-dev]

On 11/10/2017 7:54 PM, Chandler Carruth via llvm-dev wrote:
> Trying to sum-up the approaches that have been discussed, numbered in 
> the order I saw them:
>
> 1) Mangle internal names to avoid collisions.
>
> 2) Only optimize library functions when they have external linkage.
>
> 3) Switch optimizations to do cloning rather than mutating functions
>
> 4) Mark all library functions declared in system headers with some 
> attribute and key optimizations on this
>
>
> #1 doesn't seem to have much appeal.
> #3 is interesting and likely a good thing to do but not really 
> sufficient to fix the root issue.
> #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.
>
> But I think we can combine some of #4 and some of #2 to get a good 
> solution here that is practical and achievable:
>
> - Recognize external library functions, much like we already do, but 
> restrict it to external functions.
> - Recognize internal functions *with a builtin attribute* much like we 
> do external library functions.
> - Teach internalize to add the builtin attribute as it changes linkage.
>
> 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.

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?

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.)

-Eli

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project