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

Chandler Carruth via llvm-dev llvm-dev at lists.llvm.org
Mon Nov 13 13:38:36 PST 2017

On Mon, Nov 13, 2017 at 11:25 AM Friedman, Eli <efriedma at codeaurora.org> wrote:

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?

Yeah, there are a lot of issues that start to crop up here. But my hope is exactly what you say: we should handle 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.)

Sure, but I think it makes the point. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171113/bc775197/attachment.html>

More information about the llvm-dev mailing list