<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Responding to both David and Krzysztof, I'm sorry if this thread has gotten way-over-confusing. I really don't think it's this complicated: :)<div><br><div><div>On Feb 20, 2013, at 8:19 AM, David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:</div><blockquote type="cite"><p dir="ltr">> 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></p></blockquote><div><br></div><div>To Krzysztof: Right, putting IR attributes on prototypes won't work. I thought you were advocating for that.</div><br><blockquote type="cite"><p dir="ltr">
><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></blockquote><div>To David:</div><div><br></div><div>The point is that you're not marking just the calls to printf, you're marking *all* call sites compiled in the scope of fno-builtin. The indirect call case, for example:</div><div><br></div><div>void foo() {</div><div> auto fp = printf;</div><div> fp();</div><div>}</div><div><br></div><div>If built with -fno-builtin, the indirect call should be marked as such in the unoptimized IR. If devirtualization happens, the indirect call becomes a direct call and the attribute is still on the call site, preventing optimizations.</div><div><br></div><div><br></div><blockquote type="cite"><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></blockquote>To Krzysztof: exactly, unless you block inlining.<br><blockquote type="cite"><p dir="ltr">I believe Bill had suggested solving this in the first pass by not inlining incompatible attributes.</p></blockquote><div>Right, but I think that's a silly limitation, fixable by doing it right and marking call sites.</div><br></div><div>-Chris</div><br></div></body></html>