search for: nobuiltin

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

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

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: you pessimize all indirect calls in functions with at least one nobuiltin requirement > Can you give an example illus...

...decreed that that is not correct: calls to >> "operator new" *can* be optimized, but only if they come from >> new-expressions, and not if they come from explicit calls to ::operator >> new. We cannot work around this in the frontend by marking the call as >> 'nobuiltin' for two reasons: >> >> 1) The 'nobuiltin' attribute doesn't actually prevent the optimization >> (see recent patch on llvmcommits) >> 2) We can't block the optimization if the call happens through a function >> pointer, unless we also annotate all...

...mps? > 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 'nobuiltin' and another declaration without it. Another thing to note is that during LTO I plan to restrict inlining of functions to those whose attributes match. This is an overly conservative approach, but one which will minimize generating code the user didn't want/expect. This restriction is mean...

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

On May 16, 2013, at 12:36 PM, Richard Smith <richard at metafoo.co.uk> wrote: > > > Since it would probably help to quantify the complexity increase, I've implemented my more recent suggestion (patch attached). This patch allows 'nobuiltin' on a function declaration or definition, and adds a 'builtin' attribute which can only be present on a call site for a direct call to a function declared with the 'nobuiltin' attribute. The 'builtin' attribute has the effect of canceling out the 'nobuiltin' attr...

On May 15, 2013, at 8:50 PM, Richard Smith <richard at metafoo.co.uk> wrote: >> 1) The 'nobuiltin' attribute doesn't actually prevent the optimization (see recent patch on llvmcommits) >> 2) We can't block the optimization if the call happens through a function pointer, unless we also annotate all calls through function pointers as 'nobuiltin' >> >> How fe...

...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) annotate calls > Pro: you can inline calls without pessimizing the function you inline into > Con: you pessimize all indirect calls in functions with at least one > nobuiltin requirement > > Can you give an...

...r example, you could have this pseudo code: > > > auto FP = & ::operator new; // I have no idea how to actually spell this > in C++ > > IRGen into the equivalent of: > > static void *thunk(size_t NumBytes) { > return ::operator new(NumBytes); // Direct call, with nobuiltin > attribute set. > } > > auto FP = thunk; > > That way the pain of this corner case is hoisted into clang, instead of > subjecting all consumers of LLVM IR to a complexity increase. > That would violate the ABI. Another TU, built by another compiler, could do something like...

...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 'nobuiltin' and another declaration without it. You mean "So we *can* have a function declaration"... > Another thing to note is that during LTO I plan to restrict inlining of functions to those whose attributes match. This is an overly conservative approach, but one which will minimize gen...

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

...> > 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 the printf that can appear in a call may not be the printf from libc, meaning that the compiler cannot do anything to any such call that would take advantage of knowing what printf would normally do. (2) Nobuiltin attribute on some user function foo...

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

...d 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 whatever language and present in an .o file, and a function foo in C which calls strlen, which is compiled with clang. It makes sense to put the "nobuiltin" attribute on the prototype of "strlen", since this way all the callers of the strlen would know what they are dealing with. -Krzysztof -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

...ion, the C++ core working group have decreed that that is not correct: calls to "operator new" *can* be optimized, but only if they come from new-expressions, and not if they come from explicit calls to ::operator new. We cannot work around this in the frontend by marking the call as 'nobuiltin' for two reasons: 1) The 'nobuiltin' attribute doesn't actually prevent the optimization (see recent patch on llvmcommits) 2) We can't block the optimization if the call happens through a function pointer, unless we also annotate all calls through function pointers as 'nobu...

On Wed, May 15, 2013 at 8:57 PM, Chris Lattner <clattner at apple.com> wrote: > > On May 15, 2013, at 8:50 PM, Richard Smith <richard at metafoo.co.uk> wrote: > > 1) The 'nobuiltin' attribute doesn't actually prevent the optimization >>>>> (see recent patch on llvmcommits) >>>>> 2) We can't block the optimization if the call happens through a >>>>> function pointer, unless we also annotate all calls through function &gt...

...perator new has its address taken? For example, you could have this pseudo code: auto FP = & ::operator new; // I have no idea how to actually spell this in C++ IRGen into the equivalent of: static void *thunk(size_t NumBytes) { return ::operator new(NumBytes); // Direct call, with nobuiltin attribute set. } auto FP = thunk; That way the pain of this corner case is hoisted into clang, instead of subjecting all consumers of LLVM IR to a complexity increase. -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llv...

...uoted 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 whatever language and present in an .o file, and a function foo in C which calls strlen, which is compiled with clang. It makes sense to put the "nobuiltin" attribute on the prototype of "strlen", since this way all the callers of the strlen would know what they are dealing with. 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...

...ple.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. > >> &g...