[llvm-dev] [RFC][clang/llvm] Allow efficient implementation of libc's memory functions in C/C++
Xinliang David Li via llvm-dev
llvm-dev at lists.llvm.org
Tue Apr 30 08:51:18 PDT 2019
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).
> A warning should be issued if the arguments are not part of
> 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.
> 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.
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev