On Tue, Apr 7, 2020 at 10:26 AM Jonathan Wakely <jwakely....@gmail.com> wrote: > > On Mon, 6 Apr 2020 at 13:45, Nathan Sidwell <nat...@acm.org> wrote: > > > > On 4/6/20 4:34 AM, Martin Liška wrote: > > > > > > > > May I please ping Jason, Nathan and Jonathan who can help us here? > > > > On IRC Martin clarified the question as essentially 'how do you pair up > > operator new and operator delete calls?' (so you may delete them if the > > object is not used). > > > > I am not sure you're permitted to remove those calls in general. All I > > can find is [expr.new]/12 > > 'An implementation is allowed to omit a call to a replaceable global > > allocation function (17.6.2.1, 17.6.2.2). When it does so, the storage > > is instead provided by the implementation or provided by extending the > > allocation of another new-expression.' > > At https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94295#c6 Richard Smith > summarised the rules as "new-expressions, like std::allocator, may > obtain storage by calling 'operator new', but it's unspecified how > often it's called and with what arguments." > > So if our optimisation is removing the calls to base::operator new and > base::operator delete, but not the B::operator new call, then it seems > to be working at the wrong level. It should be eliding any calls to > operator new and operator delete at the point of the new-expression > and delete-expression, not leaving one call to operator new present > and then removing another one (which leaves the call "partially > removed").
Well, the question is how to identify "operator new and operator delete at the point of the new-expression and delete-expression". Currently we're just matching up "is this a new/delete operator" and the dataflow of the pointer. In the PR it was suggested the actual called methods should have the same DECL_CONTEXT. Honza suggested the context should have the "same" ODR type (or be global). You make it sound it's much harder and the parser needs to build the relation? You also suggest the "validness" is only OK in the context of std::allocator and based on the unspecifiedness of the number of allocations from the standard library. That would further suggest that we need to mark the allocation/deallocation points somehow and _not_ base the optimization on the called new/delete "function" (maybe with an exception of the global ::new and ::delete). Richard.
