similar to: [LLVMdev] [RFC] NoBuiltin Attribute

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

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

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

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

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() { >>>

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

On Feb 19, 2013, at 10:18 AM, Chris Lattner <clattner at apple.com> wrote: > 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

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

Hi All, I finally got around to cleaning up my proposal to merge `SimplifyLibCalls` into `InstCombiner`. There is still an open question or two and I am sure there are parts that could be better specified, but this is good enough to discuss. Feedback is most welcome. Abstract ======== This proposal is an attack plan for PR11895 [1]. Currently within LLVM we have two passes that are used to

On Feb 19, 2013, at 1:17 PM, Bill Wendling <wendling at apple.com> wrote: >>>>> 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

I found that LLVM optimized the IR by replacing printf with puts. I wondered which pass did this optimization? And is it common that puts is faster (and some other metric) than printf? -- Thanks Thomson -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120617/08aa6c45/attachment.html>

On Feb 20, 2013, at 8:40 AM, David Blaikie <dblaikie at gmail.com> wrote: > Sure, if you're willing to sacrifice the possible simplification of all indirect calls in any function that has even one nobuiltin requirement. > I don't understand what you mean by this. > 1) annotate calls > Pro: you can inline calls without pessimizing the function you inline into > Con:

On Aug 1, 2012, at 9:49 PM, Meador Inge <meadori at codesourcery.com> wrote: > Hi All, > > I finally got around to cleaning up my proposal to merge `SimplifyLibCalls` > into `InstCombiner`. There is still an open question or two and I am sure > there are parts that could be better specified, but this is good enough to > discuss. Feedback is most welcome. Fantastic,

On Wed, Feb 20, 2013 at 12:39 PM, Chris Lattner <clattner at apple.com> wrote: > On Feb 20, 2013, at 8:40 AM, David Blaikie <dblaikie at gmail.com> wrote: > > Sure, if you're willing to sacrifice the possible simplification of all > indirect calls in any function that has even one nobuiltin requirement. > > I don't understand what you mean by this. > 1)

Hi Thomson, the new call to puts() is inserted right away, whereas the old call to printf() is removed a bit later in SimplifyLibCalls::runOnFunction(). If you browse the code a bit and backtrack the call stack to see what happens with the return value of PrintFOpt::OptimizeFixedFormatString(), you will stumble upon this segment in SimplifyLibCalls.cpp:1703ff.: // Try to optimize this call.

On 2/19/2013 12:23 PM, Chris Lattner wrote: > > I think that there is general confusion here about what -fno-builtin does. It is *not* an attribute that affects the definition of builtin functions, it is a statement that the code being compiled in the current translation unit should change behavior. Here are the cases that I see: (1) Nobuiltin attribute on printf, telling the compiler that

On Feb 20, 2013 8:32 AM, "Krzysztof Parzyszek" <kparzysz at codeaurora.org> wrote: > > On 2/20/2013 10:19 AM, David Blaikie wrote: >> >> >> 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

On 2/18/2013 8:08 PM, Chris Lattner wrote: > > That code is presumably compiled by someone. If whoever compiles it specifies -fno-builtin, the attribute would be added to it. It doesn't affect its clients. After reading the description quoted by Bill, I'm not sure what you mean by attaching the attribute to the function body. Suppose I have my own version of strlen, written in

On Feb 19, 2013, at 6:50 AM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote: > On 2/18/2013 8:08 PM, Chris Lattner wrote: >> >> That code is presumably compiled by someone. If whoever compiles it specifies -fno-builtin, the attribute would be added to it. It doesn't affect its clients. > > After reading the description quoted by Bill, I'm not sure

On Feb 19, 2013, at 9:15 PM, Chris Lattner <clattner at apple.com> wrote: >> There are two (old) bugs related to this: a PR and a radar. They both seem to be of low priority, though. >> >> One thing that might help in this discussion is to note that attributes are *not* part of the function type (signature, whatever). So we cannot have a function declaration with