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. 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. 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. -Krzysztof -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
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 workin 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) ina.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 Iobject 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 thereis 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, hostedby 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>
(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) On Feb 20, 2013 8:19 AM, "David Blaikie" <dblaikie at gmail.com> wrote:> > 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/d2daa6ee/attachment.html>
On 2/20/2013 10:19 AM, David Blaikie wrote:> > 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?Something like that. Indirect calls could be conservatively marked as "no-builtin-everything", to limit the amount of data attached to them. Metadata could be used to indicate exactly which target functions were of interest, but it could be ignored without violating the original options.> 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.I don't think it should be marked with anything. Maybe this is the root cause of this ongoing misunderstanding. If the user compiles one function with no-builtin-printf, then only the calls to printf that were originally in this function should be subjected to this restriction. If this function is then inlined into another function that didn't have any no-builtin attributes, then calls to printf originating from that other functions are not restricted. This way you can end up with two calls to printf in the same function, one of them restricted, the other one unrestricted. -Krzysztof -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
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: :) On Feb 20, 2013, at 8:19 AM, David Blaikie <dblaikie at gmail.com> wrote:> > 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. >To Krzysztof: Right, putting IR attributes on prototypes won't work. I thought you were advocating for that.> > > > 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? >To David: 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: void foo() { auto fp = printf; fp(); } 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.> > 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. >To Krzysztof: exactly, unless you block inlining.> I believe Bill had suggested solving this in the first pass by not inlining incompatible attributes. >Right, but I think that's a silly limitation, fixable by doing it right and marking call sites. -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130220/088b9c8a/attachment.html>