similar to: [LLVMdev] _Znwm is not a builtin

On Wed, May 15, 2013 at 8:31 PM, Richard Smith <richard at metafoo.co.uk>wrote: > Hi, > > LLVM classifies _Znwm as a builtin by default. After some discussion, 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

On Wed, May 15, 2013 at 7:49 PM, Chandler Carruth <chandlerc at google.com>wrote: > On Wed, May 15, 2013 at 8:31 PM, Richard Smith <richard at metafoo.co.uk>wrote: > >> Hi, >> >> LLVM classifies _Znwm as a builtin by default. After some discussion, the >> C++ core working group have decreed that that is not correct: calls to >> "operator

On Wed, May 15, 2013 at 9:28 PM, Richard Smith <richard at metafoo.co.uk>wrote: > On Wed, May 15, 2013 at 7:49 PM, Chandler Carruth <chandlerc at google.com>wrote: > >> On Wed, May 15, 2013 at 8:31 PM, Richard Smith <richard at metafoo.co.uk>wrote: >> >>> Hi, >>> >>> LLVM classifies _Znwm as a builtin by default. After some

On Wed, May 15, 2013 at 8:28 PM, Richard Smith <richard at metafoo.co.uk>wrote: > On Wed, May 15, 2013 at 7:49 PM, Chandler Carruth <chandlerc at google.com>wrote: > >> On Wed, May 15, 2013 at 8:31 PM, Richard Smith <richard at metafoo.co.uk>wrote: >> >>> Hi, >>> >>> LLVM classifies _Znwm as a builtin by default. After some

On May 15, 2013, at 8:44 PM, Richard Smith <richard at metafoo.co.uk> wrote: > On Wed, May 15, 2013 at 8:28 PM, Richard Smith <richard at metafoo.co.uk> wrote: > On Wed, May 15, 2013 at 7:49 PM, Chandler Carruth <chandlerc at google.com> wrote: > On Wed, May 15, 2013 at 8:31 PM, Richard Smith <richard at metafoo.co.uk> wrote: > Hi, > > LLVM classifies

On Wed, May 15, 2013 at 8:46 PM, Chris Lattner <clattner at apple.com> wrote: > On May 15, 2013, at 8:44 PM, Richard Smith <richard at metafoo.co.uk> wrote: > > On Wed, May 15, 2013 at 8:28 PM, Richard Smith <richard at metafoo.co.uk>wrote: > >> On Wed, May 15, 2013 at 7:49 PM, Chandler Carruth <chandlerc at google.com>wrote: >> >>> On Wed,

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

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

On May 15, 2013, at 9:10 PM, Richard Smith <richard at metafoo.co.uk> wrote: > 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)

On May 15, 2013, at 9:10 PM, Richard Smith <richard at metafoo.co.uk> wrote: > 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)

On Wed, May 15, 2013 at 9:24 PM, Chris Lattner <clattner at apple.com> wrote: > > On May 15, 2013, at 9:10 PM, Richard Smith <richard at metafoo.co.uk> wrote: > > 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)

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

On Thu, May 16, 2013 at 10:13 AM, Chris Lattner <clattner at apple.com> wrote: > On May 15, 2013, at 10:32 PM, Richard Smith <richard at metafoo.co.uk> wrote: > > Initially, I'm just concerned about keeping the optimizations we already >>> perform, such as globalopt lowering a new/delete pair into a global, while >>> disabling the non-conforming

On May 15, 2013, at 10:32 PM, Richard Smith <richard at metafoo.co.uk> wrote: >>> Initially, I'm just concerned about keeping the optimizations we already perform, such as globalopt lowering a new/delete pair into a global, while disabling the non-conforming variations of those optimizations. But we're also permitted to merge multiple allocations into one if they have

On Wed, May 15, 2013 at 9:46 PM, Chris Lattner <clattner at apple.com> wrote: > It's not clear to me that "builtin" is the right way to model this, but it > definitely sounds like this should be an attribute on a call site (as > opposed to on the function itself). What specific kinds of optimizations > are we interested in doing to _Znwm calls? You can see the

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

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