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

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>

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>

On 30/04/2019 15:01, Guillaume Chatelet wrote:
> 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")))
I would find that exceptionally useful.  For the libm example, 
preventing LLVM from synthesising calls to other libm functions that may 
call this one would be the fine-grained control that we want.  For an 
Objective-C runtime, being able to explicitly disable synthesising ARC 
calls would be similarly useful (though I can no longer construct an 
example where LLVM does the wrong thing, so maybe this is fixed already 
in the ARC passes).

David

A POC patch is available here for discussion
https://reviews.llvm.org/D61634

On Tue, Apr 30, 2019 at 6:28 PM David Chisnall <David.Chisnall at
cl.cam.ac.uk>
wrote:
> On 30/04/2019 15:01, Guillaume Chatelet wrote:
> > 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")))
>
> I would find that exceptionally useful.  For the libm example,
> preventing LLVM from synthesising calls to other libm functions that may
> call this one would be the fine-grained control that we want.  For an
> Objective-C runtime, being able to explicitly disable synthesising ARC
> calls would be similarly useful (though I can no longer construct an
> example where LLVM does the wrong thing, so maybe this is fixed already
> in the ARC passes).
>
> David
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190507/486a856b/attachment.html>