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

Eric Fiselier via cfe-dev cfe-dev at lists.llvm.org
Sun Oct 11 14:40:10 PDT 2015


Off the top of my head I can't think of any one change that would cause
this. CCing Marshall Clow to see if he knows. I'm also CC'ing Evgenii
because he knows a lot about the visibility and inlining of libc++'s
symbols.

Originally I thought it might be related to the external instantiations of
std::basic_string,
but nothing should have changed between 3.6 and 3.7 in that regard.

> Are there any ways of building the library with minimal or no locale
support?

No and I don't think libc++ should add one. We already support way to much
feature sub-setting.



/Eric

On Sun, Oct 11, 2015 at 6:34 AM, Martin J. O'Riordan via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> 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.
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20151011/00b7ebbf/attachment.html>


More information about the cfe-dev mailing list