<div dir="ltr">On Tue, Feb 19, 2013 at 12:48 AM, Duncan Sands <span dir="ltr"><<a href="mailto:baldrick@free.fr" target="_blank" class="cremed">baldrick@free.fr</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Chris,<div class="im"><br>
<br>
On 19/02/13 03:08, Chris Lattner wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
On Feb 18, 2013, at 5:01 PM, Chandler Carruth <<a href="mailto:chandlerc@google.com" target="_blank" class="cremed">chandlerc@google.com</a><br></div><div><div class="h5">
<mailto:<a href="mailto:chandlerc@google.com" target="_blank" class="cremed">chandlerc@google.com</a>>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> In the context of LTO, it makes sense for the attribute to be on<br>
function bodies, not on prototypes.<br>
><br>
Yeah, I noticed that after sending this patch. I modified it to check the<br>
function CI is in for that attribute. Once we have support for the<br>
`-fno-builtin-FUNCTION' flag, I expect the attribute to look something<br>
like this:<br>
<br>
"no-builtin-functions" = "puts,foo,bar"<br>
<br>
<br>
I wonder... why not attach the no-builtin attribute to the call instruction?<br>
It seems like that would avoid the need of a string attribute altogether,<br>
having the frontend match up calls to specific functions which should not be<br>
considered calls to builtin functions?<br>
</blockquote>
<br>
How does this work? If I build with -fno-builtin-fputs, why would an attribute<br>
be added to a call to printf?<br>
</div></div></blockquote>
<br>
there are two parts to libcall simplification:<br>
<br>
(1) recognizing that a call is to a function we understand (eg: printf);<br>
(2) generating a new call to a library function (eg: synthesizing memcpy).<br>
<br>
Plunking an attribute on a call to say "this isn't the printf function you know"<br>
seems kind of useful to me, even if it only takes care of (1).<br></blockquote><div><br></div><div style>And what I'm wondering is if you could could annotate two cases in the frontend:<br></div><div style><br></div>
<div style>a) Mark a call to a function 'foo' as no-builtin to prevent exactly *that* callsite from being transformed based on special knowledge of the function being called.</div><div style><br></div><div style>b) Mark a function definition of 'foo' as not being subject to synthesized calls to a library function.</div>
<div style><br></div><div style>With (a), you need an attribute on the call site, but you don't need to know *which* builtin to suppress.</div><div style><br></div><div style>With (b), you need an attribute on the function definition, but I think what Chris was suggesting was that *this* half of implementing -fno-builtin could in fact be implemented without a specific list of non-builtins, which I actually mostly agree with... I'm fairly OK turning off essentially all of the libcall-synthesizing for any TU where we have calls to functions that can't be reasoned about as builtin functions.</div>
<div style><br></div><div style><br></div><div style>However, now that I think about it, I think there is an alternative to (b) that I like better, and actually goes particularly well with (a): for any 'foo' in '-fno-builtin-foo', *introduce* a declaration of the function and attach the 'no-builtin' attribute to it. If code goes on to define that function, great, attach the 'no-builtin' attribute to that. Attach it to all of the calls, etc.</div>
<div style><br></div><div style>Then, when we hit (2) above, the libcall simplification can look for an existing declaration, and if that declaration has the attribute, we don't synthesize it.</div><div style><br></div>
<div style>(I feel like this may have been Bill's original proposal, and we're circling around now... apologies if so...)</div></div></div></div>