[cfe-dev] Big program size increase with LibC++ v3.7 versus v3.6

[Martin J. O'Riordan via cfe-dev]

Hi CFE Devs,

I have recently completed upgrading our CLang/LLVM based compiler from v3.6
to v3.7, but I was noticing some significant regressions in the LibC++
test-suite.  Something has changed that is resulting in the code-size being
about 3X larger and the data size being about 2.7X larger.

Initially I suspected the compiler was at fault, so I did a series of builds
and comparisons to narrow down where the problem changes occurred.  I'll
take one test as an example:

   projects/libcxx/test/std/re/re.alg/re.alg.search/egrep.pass.cpp

With the v3.6 compiler and the v3.6 LibC++ library, this test was resulting
in a program with 122,916 Bytes of code and 6,240 Bytes of data.  With the
v3.7 compiler and the v3.7 LibC++ this became 366,708 and 16,680
respectively!  I don't know how this compares with other targets, so I can
only discuss our SHAVE program size.

At first I thought that perhaps we had broken something in LLVM, inlining
for example, so I tried the following:

   Use the v3.7 compiler to run the tests, but with the v3.6 built LibC++
   library and v3.6 LibC++ headers.  This brought the figures to 127,940
   and 6,240 respectively; much closer to the original.

But this still didn't rule out a fault in the compiler.  So I tried the
following:

   Use the v3.7 compiler to build the v3.6 LibC++ library, and again run
   the tests using this library and the v3.6 LibC++ headers.  This time I
   got 127,940 and 6,288 Bytes respectively; very close to the v3.
   compiler figures which would indicate that the compiler itself has not
   caused this regression.

So I am wondering what has happened in the sources for LibC++ v3.7 that
could cause this?

What appears to be happening, is that the library is pulling in many more
symbols (hundreds) from the libraries even though they are never actually
executed, and a lot of these are related to 'char_traits' and
wide-characters; especially in the streams and stream iterators.  I haven't
previously delved into the sources for the LibC++ library as my primary
focus is on the compiler (backend mainly), so I don't have enough experience
of the implementation of LibC++ to determine why this is.  Examining the
header changes doesn't reveal any obvious smoking gun, though I did notice
that there are some significant 'traits' related changes to '<streambuf>'.

Our platform is for embedded deployment, so I we don't need rich locale
support (C locale is fine), nor Unicode or wide-characters.  But I don't see
any configuration options in the sources for LibC++ that allows these to be
tuned for embedded systems.  Are there any ways of building the library with
minimal or no locale support?

We build LibC++ as a static library with RTTI enabled, but with threads and
exception handling disabled ('__SINGLE_THREAD__', '_LIBCPP_NO_EXCEPTIONS',
'_LIBCPP_BUILD_STATIC', '_LIBCPP_HAS_NO_THREADS' and
'_LIBCPP_HAS_NO_MONOTONIC_CLOCK' are all defined).

For LibC we are using Newlib v2.2.0, and our assembler does not support weak
externals which might be relevant, but we do support ODR linkage and garbage
collection in the linker (all data & functions in discrete sections).

Is anybody else experiencing this kind of size increase in C++ programs
since migrating to v3.7?  I have 507 LibC++ v3.7 test-cases which have
similarly increased versus the v3.6 version, mostly in the area of iterators
and streams.

Thanks,

	MartinO - Movidius Ltd.