]> git.ipfire.org Git - thirdparty/gcc.git/commit
improve std::deque::_M_reallocate_map
authorJan Hubicka <hubicka@ucw.cz>
Tue, 26 Nov 2024 12:52:09 +0000 (13:52 +0100)
committerJan Hubicka <hubicka@ucw.cz>
Tue, 26 Nov 2024 12:54:21 +0000 (13:54 +0100)
commit1729147f2b1a05ad2a4e8e2d91d1d2ba914039d6
treeac0b255d351504928449f4d206d9fd79ed5eb8c2
parentae7c0475f108f14cabcc1613df449670b1e9d1a2
improve std::deque::_M_reallocate_map

Looking into reason why we still do throw_bad_alloc in clang binary I noticed
that quite few calls come from deque::_M_reallocate_map.  This patch adds
unreachable to limit the size of realloc_map.  _M_reallocate_map is called only
if new size is smaller then max_size.  map is an array holding pointers to
entries of fixed size.

Since rellocation is done by doubling the map size, I think the maximal size of
map allocated is max_size / deque_buf_size rounded up times two.  This should
be also safe for overflows since we have extra bit.

map size is always at least 8. Theoretically this computation may be wrong for
very large T, but in that case callers should never reallocate.

On the testcase I get:
jh@shroud:~> ~/trunk-install-new4/bin/g++ -O2 dq.C -c ; size -A dq.o | grep text
.text                                              284      0
.text._ZNSt5dequeIiSaIiEE17_M_reallocate_mapEmb    485      0
.text.unlikely                                      10      0
jh@shroud:~> ~/trunk-install-new5/bin/g++ -O2 dq.C -c ; size -A dq.o | grep text
.text                                              284      0
.text._ZNSt5dequeIiSaIiEE17_M_reallocate_mapEmb    465      0
.text.unlikely                                      10      0

so this saves about 20 bytes of rellocate_map, which I think is worthwhile.
Curiously enough gcc14 does:

jh@shroud:~> g++ -O2 dq.C -c ; size -A dq.o | grep text
.text                 604      0
.text.unlikely         10      0

which is 145 bytes smaller. Obvoius difference is that _M_reallocate_map gets inlined.
Compiling gcc14 preprocessed file with trunk gives:

jh@shroud:~> g++ -O2 dq.C -S ; size -A dq.o | grep text
.text                 762      0
.text.unlikely         10      0

So inlining is due to changes at libstdc++ side, but code size growth is due to
something else.

For clang this reduced number of thris_bad_new_array_length from 121 to 61.

libstdc++-v3/ChangeLog:

* include/bits/deque.tcc (std::deque::_M_reallocate_map): Add
__builtin_unreachable check to declare that maps are not very large.
* include/bits/stl_deque.h (std::deque::size): Add __builtin_unreachable
to check for maximal size of map.

gcc/testsuite/ChangeLog:

* g++.dg/tree-ssa/deque-1.C: New test.
* g++.dg/tree-ssa/deque-2.C: New test.
gcc/testsuite/g++.dg/tree-ssa/deque-1.C [new file with mode: 0644]
gcc/testsuite/g++.dg/tree-ssa/deque-2.C [new file with mode: 0644]
libstdc++-v3/include/bits/deque.tcc
libstdc++-v3/include/bits/stl_deque.h