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?
