[LLVMdev] [RFC] NoBuiltin Attribute

[Chris Lattner]

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>