On Wed, 11 Jun 2025 at 12:13, Jonathan Wakely <jwak...@redhat.com> wrote: > > With improved memset optimizations in std::uninitialized_fill and > std::uninitialized_fill_n (see r15-4473-g3abe751ea86e34), we can make > the non-standard internal helpers __uninitialized_default and > __uninitialized_default_n use those directly instead of using std::fill > and std::fill_n respectively. And if we do that, we no longer need to > check whether the type is assignable, because avoiding std::fill means > no assignment happens. > > If the type being constructed is trivially default constructible and > trivially copy constructible, then it's unobservable if we construct one > object and copy it N-1 times, rather than constructing N objects. For > byte-sized integer types this allows the loop to be replaced with > memset. > > Because these functions are not defined for C++98 at all, we can use > if-constexpr to simplify them and remove the dispatching to members of > class template specializations. > > By removing the uses of std::fill and std::fill_n we no longer need to > include stl_algobase.h in stl_uninitialized.h which might improve > compilation time for some other parts of the library. > > libstdc++-v3/ChangeLog: > > * include/bits/stl_uninitialized.h: Do not include > bits/stl_algobase.h. > (__uninitialized_default_1, __uninitialized_default_n_1): > Remove. > (__uninitialized_default, __uninitialized_default_n): Use > 'if constexpr' and only consider triviality constructibility > not assignability when deciding on the algorithm to use. > --- > > v2: Make __uninitialized_default and __uninitialized_default_n use more > similar structure, returning early after using uninitialized_fill, and > without bothering to optimize the unlikely case where we're constructing > zero objects. > > Tested x86_64-linux.
This causes a regression in a g++ test: FAIL: g++.dg/pr104547.C -std=gnu++17 scan-tree-dump-not vrp2 "_M_default_append" So I need to examine how it affects codegen. Maybe the new code is fine, it just happens to not inline _M_default_append and inlines more elsewhere. But maybe it hurts codegen, in which case I'll need to change the approach.
