On Tue, Feb 19, 2013 at 12:48 AM, Duncan Sands <baldrick at free.fr>
wrote:
> Hi Chris,
>
>
> On 19/02/13 03:08, Chris Lattner wrote:
>
>> On Feb 18, 2013, at 5:01 PM, Chandler Carruth <chandlerc at
google.com
>> <mailto:chandlerc at google.com>> wrote:
>>
>>>
>>> > In the context of LTO, it makes sense for the attribute to
be on
>>> function bodies, not on prototypes.
>>> >
>>> Yeah, I noticed that after sending this patch. I modified it to
>>> check the
>>> function CI is in for that attribute. Once we have support for
the
>>> `-fno-builtin-FUNCTION' flag, I expect the attribute to
look
>>> something
>>> like this:
>>>
>>> "no-builtin-functions" =
"puts,foo,bar"
>>>
>>>
>>> I wonder... why not attach the no-builtin attribute to the call
>>> instruction?
>>> It seems like that would avoid the need of a string attribute
altogether,
>>> having the frontend match up calls to specific functions which
should
>>> not be
>>> considered calls to builtin functions?
>>>
>>
>> How does this work? If I build with -fno-builtin-fputs, why would an
>> attribute
>> be added to a call to printf?
>>
>
> there are two parts to libcall simplification:
>
> (1) recognizing that a call is to a function we understand (eg: printf);
> (2) generating a new call to a library function (eg: synthesizing
> memcpy).
>
> Plunking an attribute on a call to say "this isn't the printf
function you
> know"
> seems kind of useful to me, even if it only takes care of (1).
>
And what I'm wondering is if you could could annotate two cases in the
frontend:
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.
b) Mark a function definition of 'foo' as not being subject to
synthesized
calls to a library function.
With (a), you need an attribute on the call site, but you don't need to
know *which* builtin to suppress.
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.
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.
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.
(I feel like this may have been Bill's original proposal, and we're
circling around now... apologies if so...)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130219/74bc20a9/attachment.html>