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>
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 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. >You hadn't mentioned a 'builtin' attribute! =D Now I understand. Yes, I definitely think this is the right fundamental design.> Suggested transition plan: > 1) add 'builtin' attribute > 2) make Clang use it > 3) make _Znwm and friends not be implicitly builtin >This sequence is all I was looking for of course. Thanks for clarifying. I do wonder whether 'builtin' is the best tool (I think it is, but its something that I'd love to hear more opinions about from others... And if we want to keep 'nobuiltin', or just auto-upgrade to invert things? -Chandler -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130515/837026db/attachment.html>
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 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? >>> >>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.> 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/0305e831/attachment.html>
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 _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? > > 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? -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130515/d4d044f0/attachment.html>
On Wed, May 15, 2013 at 8:41 PM, Chandler Carruth <chandlerc at google.com>wrote:> 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 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. >> > > You hadn't mentioned a 'builtin' attribute! =D Now I understand. Yes, I > definitely think this is the right fundamental design. > > >> Suggested transition plan: >> 1) add 'builtin' attribute >> 2) make Clang use it >> 3) make _Znwm and friends not be implicitly builtin >> > > This sequence is all I was looking for of course. Thanks for clarifying. > > I do wonder whether 'builtin' is the best tool (I think it is, but its > something that I'd love to hear more opinions about from others... > > And if we want to keep 'nobuiltin', or just auto-upgrade to invert things? >I think 'nobuiltin' makes sense for the vast majority of cases. operator new/delete are special only because C++ allows them to be replaced by functions which are not semantically identical to the default forms. Adding 'builtin' to all direct calls to these functions when upgrading makes sense to me. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130515/ef8c18e5/attachment.html>