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
On Feb 20, 2013 8:32 AM, "Krzysztof Parzyszek" <kparzysz at codeaurora.org> wrote:> > 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 rootcause 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. Sure, if you're willing to sacrifice the possible simplification of all indirect calls in any function that has even one nobuiltin requirement. 1) annotate calls Pro: you can inline calls without pessimizing the function you inline into Con: you pessimize all indirect calls in functions with at least one nobuiltin requirement 2) annotate functions Pro: you don't penalize indirect calls Con: you either penalize functions that are inlined into, or you avoid inlining. Now, surem , I would guess the number of indirect calls that end up being simplified is probably fairly small (though I don't really have a clue) which would err in favor of (1), but I just wanted to be clear what we're trading off. Were there any other options being considered or benefits/drawbacks of these options?> > > -Krzysztof > > > -- > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hostedby The Linux Foundation -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130220/40e0370c/attachment.html>
On 2/20/2013 10:40 AM, David Blaikie wrote:> > 2) annotate functions > Pro: you don't penalize indirect calls > Con: you either penalize functions that are inlined into, or you avoid > inlining.Another problem here is that if foo is marked as no-builtin-printf, then any function inlined into foo would "inherit" that attribute. So, the inlining penalty works on both sides---whoever inlines it gets it, and whoever is inlined into it gets it.> Were there any other options being considered or benefits/drawbacks of > these options?My original thought was to associate the no-builtin attribute with the prototype of the builtin that it not to be optimized. The problem with that was that it wouldn't work well with LTO in cases where different CUs had different options. In other words, movement of code across such CUs would be very restricted (or completely prohibited), if we don't want to pessimize the attributes to the "common denominator". On the other hand, prototypes have this advantage that they can provide centralized information about a specific function without having a definition of that function. Indirect call instructions would not be affected by the no-builtin attribute since if (after resolving the indirect call) the target function turns out to be printf, a lookup for the attribute on the printf's prototype would tell us that it's a "no-builtin". -Krzysztof -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
On Feb 20, 2013, at 8:40 AM, David Blaikie <dblaikie at gmail.com> wrote:> Sure, if you're willing to sacrifice the possible simplification of all indirect calls in any function that has even one nobuiltin requirement. >I don't understand what you mean by this.> 1) annotate calls > Pro: you can inline calls without pessimizing the function you inline into > Con: you pessimize all indirect calls in functions with at least one nobuiltin requirement >Can you give an example illustrating the con? I don't see how anything is pessimized with this approach. -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130220/6f9a4a1f/attachment.html>