<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 30, 2019 at 7:01 AM Guillaume Chatelet via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">Thx for the feedback David.<div><br></div><div>So we're heading toward a broader</div><div>> __attribute__((disable_call_synthesis))</div><div><br></div><div>David what do you think about the additional version that restrict the effect to a few named functions?</div><div>> e.g. __attribute__((disable_call_synthesis("memset", "memcpy", "sqrt")))<br></div><div><br></div></div></div></blockquote><div><br></div><div>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:</div><div><br></div><div>__attribute__((no_runtime_for("memcpy", "memset", "sqt")))</div><div><br></div><div>It still allows compiler to synthesize calls to builtins that are *guaranteed* to be inline expanded later (if that is available).</div><div><br></div><div>David</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div></div><div>A warning should be issued if the arguments are not part of RuntimeLibcalls.def.</div><div><br></div><div>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.</div><div><br></div><div>Thx,</div><div>Guillaume</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 29, 2019 at 10:48 AM David Chisnall via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 26/04/2019 12:47, Guillaume Chatelet via llvm-dev wrote:<br>
> 1.2 A specific attribute to disable synthesis of all libc calls<br>
> __attribute__((disable_libc_call_synthesis))<br>
> With this one we are losing precision and we may inline too much. There <br>
> is also the question of what is considered a libc function, LLVM mainly <br>
> defines target library calls.<br>
<br>
Target library is probably more relevant than libc. We have a number of <br>
issues with libm on tier 2 platforms for FreeBSD without assembly fast <br>
paths. This requires work-arounds for the fact that clang likes to say <br>
'oh, this function seems to be calling X on the result of Y, and I know <br>
that this can be more efficient if you replace that sequence with Z', <br>
ignoring the fact that this case is an implementation of Z.<br>
<br>
The same thing is true in Objective-C runtime implementations, where we <br>
need to be careful to avoid LLVM performing optimisations on the ARC <br>
functions that result in infinite recursion.<br>
<br>
There are numerous cases of compiler-rt suffering from the same issue.<br>
<br>
TL;DR: This is a really important problem for clang and your proposed <br>
solution 1 looks like it is far more broadly applicable.<br>
<br>
David<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div>