llvm dev - Feb 2013 - [LLVMdev] [RFC] NoBuiltin Attribute

On 2/19/2013 12:23 PM, Chris Lattner wrote:
>
> I think that there is general confusion here about what -fno-builtin does. 
It is *not* an attribute that affects the definition of builtin functions, it is
a statement that the code being compiled in the current translation unit should
change behavior.
Here are the cases that I see:
(1) Nobuiltin attribute on printf, telling the compiler that the printf 
that can appear in a call may not be the printf from libc, meaning that 
the compiler cannot do anything to any such call that would take 
advantage of knowing what printf would normally do.
(2) Nobuiltin attribute on some user function foo, telling the compiler 
that we don't want it to perform any optimizations related to the 
knowledge about builtins (or printf in particular, if it's 
nobuiltin-printf) in function foo.

Case (1) would imply (2), and not only for foo, but for all functions. 
On the other hand, (2) does not imply (1).  In case (1) it may be 
considered an error to have conflicting attribute for printf in 
different compilation units, if the attribute is associated with the 
prototype of printf.  However, it doesn't have to be an error if the 
attribute is actually present at every function call (instead of being 
attached to the prototype).

Case (2) would only have the attribute on calls that are originally in 
the body of foo.  Otherwise we would run into trouble with inlining even 
without LTO.

This seems to agree with what you wrote (here and in other replies), and 
I suspect that the difference may be in some details of how we look at it.

I would suggest using separate compiler options to denote the two cases, 
something like:
(1) -fno-builtin-printf
(2) -fno-builtins-in-foo (or something of that nature).

There is also the problem of function overload in C++, templates, 
namespaces, etc. and I have no idea how to differentiate between 
different foos in a compiler option (without using mangled names). 
(This is not so much a problem for the real builtins, as they are mostly 
unmangled.)

-Krzysztof

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
hosted by The Linux Foundation

On Feb 19, 2013, at 10:50 AM, Krzysztof Parzyszek <kparzysz at
codeaurora.org> wrote:
> On 2/19/2013 12:23 PM, Chris Lattner wrote:
>> 
>> I think that there is general confusion here about what -fno-builtin
does.  It is *not* an attribute that affects the definition of builtin
functions, it is a statement that the code being compiled in the current
translation unit should change behavior.
> 
> Here are the cases that I see:
> (1) Nobuiltin attribute on printf, telling the compiler that the printf
that can appear in a call may not be the printf from libc, meaning that the
compiler cannot do anything to any such call that would take advantage of
knowing what printf would normally do.
What is the use case of this?  This makes no sense for LTO, and minimal sense
for the non-LTO case.  What problem are you trying to solve here?

-Chris

On 2/19/2013 12:58 PM, Chris Lattner wrote:
>
> What is the use case of this?  This makes no sense for LTO, and minimal
sense for the non-LTO case.  What problem are you trying to solve here?
Cases where users write their own replacements of standard functions. 
It's not legal from the standard's perspective, but it happens.  As a 
matter of fact, this would be my primary goal here...

-Krzysztof

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
hosted by The Linux Foundation