[Bug libstdc++/60621] New: std::vector::emplace_back generates massively more code than push_back

[Bug libstdc++/60621] New: std::vector::emplace_back generates massively more code than push_back

[mutz at kde dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60621

            Bug ID: 60621
           Summary: std::vector::emplace_back generates massively more
                    code than push_back
           Product: gcc
           Version: 4.7.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: mutz at kde dot org

Created attachment 32429
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32429&action=edit
Source of the programme used to generate the mentioned numbers

Compiling the attached program on Linux AMD64 with the following command lines:

    $ g++ -O2 -std=c++11 -o emplace-vs-push_back{.pb,.cpp}
    $ g++ -O2 -std=c++11 -o emplace-vs-push_back{.eb,.cpp} -DEMPLACE_BACK

and stripping the resulting executables:

    $ strip emplace-vs-push_back.*

I get the following sizes:

    $ size emplace-vs-push_back.*
       text    data     bss     dec     hex filename
       5570     696      40    6306    18a2 emplace-vs-push_back.eb
       4338     672      40    5050    13ba emplace-vs-push_back.pb

IOW: the emplace_back version generates roughly 1K more text (code).

This is surprising, since functionally, emplace_back is the same as
push_back(S&&), except that it saves one move ctor and one dtor call due to
in-place construction. This should result in _less_ code generated, not more.

   $ g++ -v
   Using built-in specs.
   COLLECT_GCC=g++
   COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper
   Target: x86_64-linux-gnu
   Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.2-5'
--with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs
--enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.7 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object
--enable-plugin --enable-objc-gc --with-arch-32=i586 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
   Thread model: posix
   gcc version 4.7.2 (Debian 4.7.2-5)

[Bug libstdc++/60621] std::vector::emplace_back generates massively more code than push_back

[glisse at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60621

--- Comment #1 from Marc Glisse <glisse at gcc dot gnu.org> ---
Some things that help:
-fabi-version=0
-fwhole-program (so it knows emplace_back won't be used anywhere else, and it
can inline it and remove the unneeded paths)

[Bug libstdc++/60621] std::vector::emplace_back generates massively more code than push_back

[marc at kdab dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60621

--- Comment #2 from marc at kdab dot com ---
Yes, that helps a bit, but emplace_back still generates larger code than the
corresponding rvalue-push_back. Considering that the latter also needs to
generate the implicitly defined move ctor for S, this is still somewhat
surprising and runs counter to the motivation to have emplace_back in the first
place.

[Bug libstdc++/60621] std::vector::emplace_back generates massively more code than push_back

[marc at kdab dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60621

marc at kdab dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #32429|0                           |1
        is obsolete|                            |

--- Comment #4 from marc at kdab dot com ---
Created attachment 34723
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34723&action=edit
New version of the test programme.