This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libstdc++/60621] std::vector::emplace_back generates massively more code than push_back
- From: "marc at kdab dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Wed, 11 Feb 2015 11:12:46 +0000
- Subject: [Bug libstdc++/60621] std::vector::emplace_back generates massively more code than push_back
- Auto-submitted: auto-generated
- References: <bug-60621-4 at http dot gcc dot gnu dot org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60621
--- Comment #3 from marc at kdab dot com ---
Now, what is _really_ weird is that push_back(T&&) _calls_ emplace_back(). I
also tried the magic incantation
g++ --param large-unit-insns=100000000 \
--param inline-unit-growth=100000000 \
--param max-inline-insns-single=100000000 \
--param large-function-growth=100000000 \
--param large-function-insns=100000000 -O2
to no avail. I can get the two version to within 80 bytes of text of each other
by adding -fno-exceptions, so it's probably related to that. The (implicit)
move ctor of S cannot throw, but the std::string(const char*) ctor can. Ie. in
the rvalue-push_back case, emplace_back only dabbles in noexcept operations,
and in the 3xconst char* case, it needs to deal with three throwing ctors.
I can reduce the text size to within a few hundreds of bytes by marking both
emplace_back and _M_emplace_back_aux as __attribute__((always_inline)), so
something prevents gcc from inlining even when turning the inlining paramters
all the way up.
I can also reduce the text size by passing std::strings instead of conat
char*s:
text data bss dec hex filename
5628 672 40 6340 18c4 emplace-vs-push_back.eb
4991 672 40 5703 1647 emplace-vs-push_back.nt
4516 648 40 5204 1454 emplace-vs-push_back.pb
(where .nt is EMPLACE_BACK_NOTHROW). Still a large gap...
Have we accepted another auto_ptr into the standard? :)