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

[Xinliang David Li via llvm-dev]

On Mon, Nov 13, 2017 at 11:25 AM, Friedman, Eli via llvm-dev <
llvm-dev at lists.llvm.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?
>


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.


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


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.

David


>
>
> -Eli
>
> --
> Employee of Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
> Foundation Collaborative Project
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171113/d15b6934/attachment.html>