[LLVMdev] [RFC] NoBuiltin Attribute

[David Blaikie]

On Feb 20, 2013 7:58 AM, "Krzysztof Parzyszek" <kparzysz at codeaurora.org>
wrote:
>
> On 2/19/2013 11:11 PM, Chris Lattner wrote:
>>
>>
>> I still really have no idea what problem you think you are solving.
>
>
> Dealing with different attributes on different functions.
>
> --- a.c ---
> void func_a() {
>   printf(...);
> }
>
> --- b.c ---
> void func_b() {
>   printf(...);
>   func_a();
> }
>
> a.c is compiled with no-builtin-printf, b.c has no such options.
>
> The prototype approach (no-builtin on the prototype of printf) won't work
in case like this, when the no-builtin attributes are not identical across
all the compilation units.
>
> Putting this attribute on all calls to printf (and all indirect calls) in
a.c should work fine.

I'm still not understanding a few things in this thread, including one
here: if you annotate only the calls to print (say) then how do you handle
the indirect calls that the back end might yet optimize down to a constant
& then attempt to simplify? Would all indirect calls be annotated with all
the unsimplifiable function names?

> Putting the attribute on the caller of printf, i.e. "func_a" is what I
object to.  If it's in the form of "define @func_a() no-builtin-printf
{...body...}", then the attribute may be lost during inlining of func_a.

I believe Bill had suggested solving this in the first pass by not inlining
incompatible attributes.

> If this is solved by transferring the attribute to the calls, then there
is no need for any specific association of the attribute with func_a, since
it can be placed on the calls from the beginning.

I'm not quite sure what you mean by 'can be placed on calls from the
beginning'. One of the core issues here is LTO where two bit code files
were compiled with different options and then linked together - then one
function from one bitcode is inclined into a function from the other - in
this case there was no opportunity to have marked the latter with the right
attribute ahead of time.

>
>
> -Krzysztof
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted
by The Linux Foundation
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130220/b11f5f5a/attachment.html>