[LLVMdev] [RFC] NoBuiltin Attribute

Chris Lattner clattner at apple.com
Tue Feb 19 10:30:54 PST 2013


On Feb 19, 2013, at 1:18 AM, Chandler Carruth <chandlerc at google.com> wrote:
> 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.

Yes, this is necessary.

> 
> b) Mark a function definition of 'foo' as not being subject to synthesized calls to a library function.

I don't understand why this is either necessary or sufficient.

> 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.

Among other problems, doing this would requires us to:

1. Add each of these to llvm.used (or add other hacks) to prevent them from being used.
2. Add a *ton* of function prototypes when -fno-builtin is passed (since there are dozens or hundreds of different "builtin" functions that we optimize.
3. Every time the optimizer learns to optimize some new libcall, we would have to change every llvm frontend that wants -fno-builtin to add the prototype.

Lets not do this! :)

-Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130219/d70d4c6d/attachment.html>


More information about the llvm-dev mailing list