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. -bw -------------- next part -------------- A non-text attachment was scrubbed... Name: clang.nobuiltin.diff Type: application/octet-stream Size: 587 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130218/b329ab5d/attachment.obj> -------------- next part -------------- A non-text attachment was scrubbed... Name: nobuiltin.diff Type: application/octet-stream Size: 7487 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130218/b329ab5d/attachment-0001.obj> -------------- next part --------------
Awesome work on the Attributes Bill! I see them now in the bitcode files. I can't wait continue my work that needs to compile functions differently as mips16 or mips32 depending on the attributes. On 02/18/2013 01:54 PM, Bill Wendling 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. > > -bw > > > > > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
Thank you! Let me know if you would like some extra functionality or changes in them. :) -bw On Feb 18, 2013, at 2:51 PM, Reed Kotler <rkotler at mips.com> wrote:> Awesome work on the Attributes Bill! > > I see them now in the bitcode files. > > I can't wait continue my work that needs to compile functions differently as mips16 or mips32 depending on the attributes. > > On 02/18/2013 01:54 PM, Bill Wendling 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. >> >> -bw >> >> >> >> >> >> >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > >
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. -Chris
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" -bw
On 2/18/2013 6:45 PM, Chris Lattner wrote:> > In the context of LTO, it makes sense for the attribute to be on function bodies, not on prototypes.What if the body is defined in some external library? -Krzysztof -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation