[llvm-dev] [RFC][clang/llvm] Allow efficient implementation of libc's memory functions in C/C++

[Guillaume Chatelet via llvm-dev]

Thx for the feedback David.

So we're heading toward a broader
> __attribute__((disable_call_synthesis))

David what do you think about the additional version that restrict the
effect to a few named functions?
> e.g. __attribute__((disable_call_synthesis("memset", "memcpy", "sqrt")))

A warning should be issued if the arguments are not part of
RuntimeLibcalls.def.

Also I'd like to get your take on whether it makes sense to have this
attribute apply to functions only or at module level as well.

Thx,
Guillaume

On Mon, Apr 29, 2019 at 10:48 AM David Chisnall via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> On 26/04/2019 12:47, Guillaume Chatelet via llvm-dev wrote:
> >      1.2 A specific attribute to disable synthesis of all libc calls
> > __attribute__((disable_libc_call_synthesis))
> > With this one we are losing precision and we may inline too much. There
> > is also the question of what is considered a libc function, LLVM mainly
> > defines target library calls.
>
> Target library is probably more relevant than libc. We have a number of
> issues with libm on tier 2 platforms for FreeBSD without assembly fast
> paths.  This requires work-arounds for the fact that clang likes to say
> 'oh, this function seems to be calling X on the result of Y, and I know
> that this can be more efficient if you replace that sequence with Z',
> ignoring the fact that this case is an implementation of Z.
>
> The same thing is true in Objective-C runtime implementations, where we
> need to be careful to avoid LLVM performing optimisations on the ARC
> functions that result in infinite recursion.
>
> There are numerous cases of compiler-rt suffering from the same issue.
>
> TL;DR: This is a really important problem for clang and your proposed
> solution 1 looks like it is far more broadly applicable.
>
> David
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://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/20190430/f7bf5e5d/attachment.html>