[LLVMdev] [RFC] NoBuiltin Attribute

[Chris Lattner]

On Feb 18, 2013, at 10:31 PM, Bill Wendling <wendling at apple.com> wrote:

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

Ok, this makes a lot of sense to me.

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

Sounds good, much of TLI can just disappear when this happens, woot.

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

I guess I'm just asking "how much do we care" about that use case?  Is it worth uglifying IR dumps?

-Chris