[LLVMdev] [RFC] NoBuiltin Attribute

[Chandler Carruth]

On Mon, Feb 18, 2013 at 4:49 PM, Bill Wendling <wendling at apple.com> wrote:

> On Feb 18, 2013, at 4:45 PM, Chris Lattner <clattner at apple.com> wrote:
>
> >
> > On Feb 18, 2013, at 1:54 PM, Bill Wendling <wendling at apple.com> wrote:
> >
> >> Hi LLVMites!
> >>
> >> This patch adds the 'nobuiltin' attribute to to LLVM. This is needed
> during LTO, which right now ignores this attribute and command line flag. I
> want to make this an IR-level attribute instead of a target-dependent
> attribute because it's used during IR modification and not code generation.
> >>
> >
> > Hi Bill,
> >
> > I think the concept of this patch makes sense, but the implementation
> does not.
> >
> > I have:
> >
> > void foo() {
> >  printf("hello\n");
> > }
> >
> > and I build with -fno-builtin-puts.  If I understand correctly, *foo*
> will be marked with "nobuiltin", but this code in simplifylibcalls looks at
> the printf:
> >
> > Value *LibCallSimplifier::optimizeCall(CallInst *CI) {
> > +  Function *F = CI->getCalledFunction();
> > +  if (F->hasFnAttribute(Attribute::NoBuiltin)) return 0;
> >   return Impl->optimizeCall(CI);
> > }
> >
> > In the context of LTO, it makes sense for the attribute to be on
> function bodies, not on prototypes.
> >
> Yeah, I noticed that after sending this patch. I modified it to check the
> function CI is in for that attribute. Once we have support for the
> `-fno-builtin-FUNCTION' flag, I expect the attribute to look something like
> this:
>
>         "no-builtin-functions" = "puts,foo,bar"
>

I wonder... why not attach the no-builtin attribute to the call
instruction? It seems like that would avoid the need of a string attribute
altogether, having the frontend match up calls to specific functions which
should not be considered calls to builtin functions?

For the general case of just '-ffreestanding' or whichever, you might do
something different if annotating every call instruction is prohibitively
expensive.

But I've not thought about this deeply, I just find the idea of having the
backend be responsible for matching up the function names somewhat
distasteful.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130218/e577857f/attachment.html>