[LLVMdev] [RFC] NoBuiltin Attribute

[Bill Wendling]

On Feb 18, 2013, at 6:10 PM, Chris Lattner <clattner at apple.com> wrote:

> On Feb 18, 2013, at 4:49 PM, Bill Wendling <wendling at apple.com> wrote:
>>> 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.
> 
> Was that in the patch you committed?  What specific patch are you looking for?
> 
Yeah, that was in the one that I committed. I basically want something like this:

  define void @foo() "no-builtin" {
    call void @printf()
  }

And then the `call' to printf would check for the "no-builtin" attribute on `@foo' to determine if it can convert it to `puts'. Having the attribute on the declaration of `printf' doesn't help us here. And I'm not sure if having it on the call would be beneficial either.

>> 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 guess this could work, this means that simplifylibcalls (and others) would check this instead of TargetLibraryInfo?
> 
Yes.

> Out of curiosity, how important is -fno-builtin-foo?  Isn't it enough to just have -fno-builtin-foo disable *all* builtin optimizations for the unit of code being compiled?  This is overly conservative - is that actually a problem for something?
> 
Being overly conservative will of course keep the correct semantics for the program. I suppose that there could be some people who have their own special version of a builtin that they want to use, but they don't want all builtin optimizations to be disabled.

-bw