<div dir="ltr">On Mon, Feb 18, 2013 at 4:49 PM, Bill Wendling <span dir="ltr"><<a href="mailto:wendling@apple.com" target="_blank" class="cremed">wendling@apple.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Feb 18, 2013, at 4:45 PM, Chris Lattner <<a href="mailto:clattner@apple.com" class="cremed">clattner@apple.com</a>> wrote:<br>

<br>
><br>
> On Feb 18, 2013, at 1:54 PM, Bill Wendling <<a href="mailto:wendling@apple.com" class="cremed">wendling@apple.com</a>> wrote:<br>
><br>
>> Hi LLVMites!<br>
>><br>
>> This patch adds the 'nobuiltin' attribute to to LLVM. This is needed during LTO, which right now ignores this attribute and command line flag. I want to make this an IR-level attribute instead of a target-dependent attribute because it's used during IR modification and not code generation.<br>

>><br>
><br>
> Hi Bill,<br>
><br>
> I think the concept of this patch makes sense, but the implementation does not.<br>
><br>
> I have:<br>
><br>
> void foo() {<br>
>  printf("hello\n");<br>
> }<br>
><br>
> and I build with -fno-builtin-puts.  If I understand correctly, *foo* will be marked with "nobuiltin", but this code in simplifylibcalls looks at the printf:<br>
><br>
> Value *LibCallSimplifier::optimizeCall(CallInst *CI) {<br>
> +  Function *F = CI->getCalledFunction();<br>
> +  if (F->hasFnAttribute(Attribute::NoBuiltin)) return 0;<br>
>   return Impl->optimizeCall(CI);<br>
> }<br>
><br>
> In the context of LTO, it makes sense for the attribute to be on function bodies, not on prototypes.<br>
><br>
</div>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:<br>

<br>
        "no-builtin-functions" = "puts,foo,bar"<br></blockquote><div><br></div><div style>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?</div>
<div style><br></div><div style>For the general case of just '-ffreestanding' or whichever, you might do something different if annotating every call instruction is prohibitively expensive.</div><div><br></div><div style>
But I've not thought about this deeply, I just find the idea of having the backend be responsible for matching up the function names somewhat distasteful.</div></div></div></div>