On Tue, Apr 7, 2020 at 1:46 PM Jonathan Wakely <jwakely....@gmail.com> wrote: > > On Tue, 7 Apr 2020 at 12:40, Richard Biener <richard.guent...@gmail.com> > wrote: > > > > On Tue, Apr 7, 2020 at 1:30 PM Jonathan Wakely <jwakely....@gmail.com> > > wrote: > > > > > > On Mon, 6 Apr 2020 at 13:45, Nathan Sidwell wrote: > > > > The both operator new and operator delete are looked up in the same > > > > manner. The std does not require a 'matching pair' be found. but it is > > > > extremely poor form for a class to declare exactly one of operator > > > > {new,delete}. > > > > > > There are unfortunately several such example in the standard! > > > > > > I wonder how much benefit we will really get from trying to make this > > > optimisation too general. > > > > > > Just eliding (or coalescing) implicit calls to ::operator new(size_t) > > > and ::operator delete(void*, size_t) (and the [] and align_val_t forms > > > of those) probably covers 99% of real cases. > > > > IIRC the only reason to have the optimization was to fully elide > > STL containers when possible. That brings in allocators and > > thus non ::new/::delete allocations. > > But the vast majority of containers are used with std::allocator, and > we control that. > > Wouldn't it be simpler to add __builtin_operator_new and > __builtin_operator_delete like clang has, then make std::allocator use > those, and limit the optimizations to uses of those built-ins?
Sure, that's a viable implementation strathegy. Another might be void delete (void *) __attribute__((matching_new(somewhere::new))); and thus allow the user to relate a new/delete pair (here the FE would do lookup for 'new' and record for example the mangled assembler name). That is, we usually try to design a mechanism that's more broadly usable. But yes, we match malloc/free so matching ::new/::delete by aliasing them to __builtin_operator_new and __builtin_operator_delete is fair enough. Not easily usable by other languages with custom allocation though (fortran allocate/deallocate anyone? that's currently inlined to expose underlying malloc/free calls for similar reasons) Richard.