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 feasible would it be to make the 'builtin-ness' of _Znwm etc be opt-in rather than opt-out? Is there some other option we could pursue? >> >> Wow, this was spectacularly unclear, sorry about that. To avoid confusion, I'm suggesting that we add a 'builtin' attribute, and do not treat a call to _Znwm as a builtin call unless it has the attribute. >> > > 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? > > 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 sufficiently similar lifetimes.So your proposal is for Clang to slap the attribute on explicit calls to ::operator new, but any other use of the symbol (e.g. from C code or something else weird) can be optimized? If so, using nobuiltin seems perfectly fine to me. It seems like there is no auto-upgrade required. -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130515/51024136/attachment.html>
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 >>>>> pointers as 'nobuiltin' >>>>> >>>>> How feasible would it be to make the 'builtin-ness' of _Znwm etc be >>>>> opt-in rather than opt-out? Is there some other option we could pursue? >>>>> >>>> >> Wow, this was spectacularly unclear, sorry about that. To avoid >> confusion, I'm suggesting that we add a 'builtin' attribute, and do not >> treat a call to _Znwm as a builtin call unless it has the attribute. >> >> >> >> 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? >> > > 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 > sufficiently similar lifetimes. > > > So your proposal is for Clang to slap the attribute on explicit calls to > ::operator new, but any other use of the symbol (e.g. from C code or > something else weird) can be optimized? >No, because Clang cannot statically detect which indirect calls might call ::operator new. Instead, my proposal is to add a 'builtin' attribute to LLVM, and then for clang to add that attribute to the calls which can be optimized. If you think the C code / weird cases are important, a more nuanced option springs to mind: * Allow the 'nobuiltin' attribute on function declarations * Add a 'builtin' attribute, permitted only on direct calls to 'nobuiltin' functions, which overrides the 'nobuiltin' attribute on the function Would that be preferable? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130515/2bf3d128/attachment.html>
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) >>> 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 feasible would it be to make the 'builtin-ness' of _Znwm etc be opt-in rather than opt-out? Is there some other option we could pursue? >>> >>> Wow, this was spectacularly unclear, sorry about that. To avoid confusion, I'm suggesting that we add a 'builtin' attribute, and do not treat a call to _Znwm as a builtin call unless it has the attribute. >>> >> >> 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? >> >> 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 sufficiently similar lifetimes. > > So your proposal is for Clang to slap the attribute on explicit calls to ::operator new, but any other use of the symbol (e.g. from C code or something else weird) can be optimized? > > No, because Clang cannot statically detect which indirect calls might call ::operator new. Instead, my proposal is to add a 'builtin' attribute to LLVM, and then for clang to add that attribute to the calls which can be optimized.Ugh. Having two different ways to represent "the same" thing is deeply unfortunate. I don't understand the full issue here though, how can you get an indirect call to ::operator new? Can you take its address in C++?> If you think the C code / weird cases are important,It is not (to me at least), I just want to understand the design point. -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130515/7a812aa9/attachment.html>
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) >>> 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 feasible would it be to make the 'builtin-ness' of _Znwm etc be opt-in rather than opt-out? Is there some other option we could pursue? >>> >>> Wow, this was spectacularly unclear, sorry about that. To avoid confusion, I'm suggesting that we add a 'builtin' attribute, and do not treat a call to _Znwm as a builtin call unless it has the attribute. >>> >> >> 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? >> >> 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 sufficiently similar lifetimes. > > So your proposal is for Clang to slap the attribute on explicit calls to ::operator new, but any other use of the symbol (e.g. from C code or something else weird) can be optimized? > > No, because Clang cannot statically detect which indirect calls might call ::operator new. Instead, my proposal is to add a 'builtin' attribute to LLVM, and then for clang to add that attribute to the calls which can be optimized. > > If you think the C code / weird cases are important, a more nuanced option springs to mind: > > * Allow the 'nobuiltin' attribute on function declarations > * Add a 'builtin' attribute, permitted only on direct calls to 'nobuiltin' functions, which overrides the 'nobuiltin' attribute on the function > > Would that be preferable?Just curious: will this fix the issue that we discussed last month in the context of r179071 regarding the need to compile with -fno-builtin if you have code with custom new operators? (http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130408/170888.html) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130515/80c7ea75/attachment.html>