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

[Chandler Carruth via llvm-dev]

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>