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 ::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 '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? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130515/ed622357/attachment.html>
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 ::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 > '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? >I think we should just fix this when we build the system which allows optimizing new expressions. Specifically, when we introduce a way to mark new expressions for LLVM to optimize, that's the time to make the builtin-ness of _Znwm opt-in instead of opt-out. Doing anything before then would I think be really unfortunate for performance -- this optimization does fire reasonably frequently. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130515/a3494131/attachment.html>
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 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 >> '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? >> > > I think we should just fix this when we build the system which allows > optimizing new expressions. Specifically, when we introduce a way to mark > new expressions for LLVM to optimize, that's the time to make the > builtin-ness of _Znwm opt-in instead of opt-out. >This 'builtin' attribute would *be* building the system which allows optimizing new-expressions. Suggested transition plan: 1) add 'builtin' attribute 2) make Clang use it 3) make _Znwm and friends not be implicitly builtin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130515/5804e1dd/attachment.html>