[LLVMdev] [RFC] NoBuiltin Attribute

[Chris Lattner]

On Feb 19, 2013, at 2:45 PM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote:

> On 2/19/2013 1:50 PM, Chris Lattner wrote:
>> 
>> How is this not handled by handling fno-builtin by putting an attribute on the code being compiled?
> 
> Regardless of which solution you consider, it is always "putting an attribute on the code being compiled", the question is where exactly and what we do with it

No, it isn't.  Putting it on IR prototypes is *not* putting the attribute on the code being compiled, it is putting it on something that is transient, that does not survive LTO merges, and that is aggressively deleted when unused.  This is not the mechanism to build whatever feature it is that you think you're looking for.

> .  I'm opposed to putting the attribute on the definitions of the callers of functions indicated with -fno-builtin-<something>.
> 
> If the user says -fno-builtin-printf, then all callers of printf would need to be marked as "nobuiltin".

Yes, or "no-builtin=printf" if we bother to implement fine grained control.

>  As your example demonstrates, we don't always know the exact set of callers of printf, since there can be indirect calls that may only later be resolved to direct calls.

The attribute would also be put on all indirect calls: when/if they get devirtualized, exactly the right thing happens.

> Putting attributes on caller's bodies will pose difficulties during link-time inlining, which was also illustrated by your example from earlier in this branch of this thread.

I don't think you understand how link-time inlining works.

> If we implement it this way now, we may not be able to change it later, especially if we want to have backward compatibility of bitcode (i.e. future LLVMs compiling past bitcodes).

I still really have no idea what problem you think you are solving.  Please give me a specific code example plus a series of steps to reproduce the issue you are imagining, exactly as I did up-thread.

Thanks!

-Chris