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

[Xinliang David Li via llvm-dev]

On Tue, Apr 30, 2019 at 7:01 AM Guillaume Chatelet via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> 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")))
>
>
Nit: the attribute basically just states that there is no runtime support
for these functions in this context, so why not directly name it so:

__attribute__((no_runtime_for("memcpy", "memset", "sqt")))

It still allows compiler to synthesize calls to builtins that are
*guaranteed* to be inline expanded later (if that is available).

David




> 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
>>
> _______________________________________________
> 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/016a39f7/attachment.html>