<p dir="ltr">(And somehow I ended up adding a random non functioning email alias to the 'to' line in my last reply, removed in this reply. Sorry about that)</p>
<div class="gmail_quote">On Feb 20, 2013 8:19 AM, "David Blaikie" <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p dir="ltr"><br>
On Feb 20, 2013 7:58 AM, "Krzysztof Parzyszek" <<a href="mailto:kparzysz@codeaurora.org" target="_blank">kparzysz@codeaurora.org</a>> wrote:<br>
><br>
> On 2/19/2013 11:11 PM, Chris Lattner wrote:<br>
>><br>
>><br>
>> I still really have no idea what problem you think you are solving.<br>
><br>
><br>
> Dealing with different attributes on different functions.<br>
><br>
> --- a.c ---<br>
> void func_a() {<br>
>   printf(...);<br>
> }<br>
><br>
> --- b.c ---<br>
> void func_b() {<br>
>   printf(...);<br>
>   func_a();<br>
> }<br>
><br>
> a.c is compiled with no-builtin-printf, b.c has no such options.<br>
><br>
> 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.<br>
><br>
> Putting this attribute on all calls to printf (and all indirect calls) in a.c should work fine.</p>
<p dir="ltr">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?</p>


<p dir="ltr">> 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.</p>


<p dir="ltr">I believe Bill had suggested solving this in the first pass by not inlining incompatible attributes.</p>
<p dir="ltr"> > 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.</p>


<p dir="ltr">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.</p>


<p dir="ltr">><br>
><br>
> -Krzysztof<br>
><br>
> -- <br>
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation<br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</p>
</blockquote></div>