On 2/19/2013 1:50 PM, Chris Lattner wrote:> > How is this not handled by handling fno-builtin by putting an attribute on the code being compiled?Regardless of which solution you consider, it is always "putting an attribute on the code being compiled", the question is where exactly and what we do with it. I'm opposed to putting the attribute on the definitions of the callers of functions indicated with -fno-builtin-<something>. If the user says -fno-builtin-printf, then all callers of printf would need to be marked as "nobuiltin". As your example demonstrates, we don't always know the exact set of callers of printf, since there can be indirect calls that may only later be resolved to direct calls. Putting attributes on caller's bodies will pose difficulties during link-time inlining, which was also illustrated by your example from earlier in this branch of this thread. If we implement it this way now, we may not be able to change it later, especially if we want to have backward compatibility of bitcode (i.e. future LLVMs compiling past bitcodes). -Krzysztof -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
On Feb 19, 2013, at 2:45 PM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote:> On 2/19/2013 1:50 PM, Chris Lattner wrote: >> >> How is this not handled by handling fno-builtin by putting an attribute on the code being compiled? > > Regardless of which solution you consider, it is always "putting an attribute on the code being compiled", the question is where exactly and what we do with itNo, it isn't. Putting it on IR prototypes is *not* putting the attribute on the code being compiled, it is putting it on something that is transient, that does not survive LTO merges, and that is aggressively deleted when unused. This is not the mechanism to build whatever feature it is that you think you're looking for.> . I'm opposed to putting the attribute on the definitions of the callers of functions indicated with -fno-builtin-<something>. > > If the user says -fno-builtin-printf, then all callers of printf would need to be marked as "nobuiltin".Yes, or "no-builtin=printf" if we bother to implement fine grained control.> As your example demonstrates, we don't always know the exact set of callers of printf, since there can be indirect calls that may only later be resolved to direct calls.The attribute would also be put on all indirect calls: when/if they get devirtualized, exactly the right thing happens.> Putting attributes on caller's bodies will pose difficulties during link-time inlining, which was also illustrated by your example from earlier in this branch of this thread.I don't think you understand how link-time inlining works.> If we implement it this way now, we may not be able to change it later, especially if we want to have backward compatibility of bitcode (i.e. future LLVMs compiling past bitcodes).I still really have no idea what problem you think you are solving. Please give me a specific code example plus a series of steps to reproduce the issue you are imagining, exactly as I did up-thread. Thanks! -Chris
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