[LLVMdev] [RFC] NoBuiltin Attribute

[David Blaikie]

(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>