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

[Eric Fiselier via cfe-dev]

I tried building and testing libc++ 3.6 on Linux but I couldn't easily
reproduce. I built the 3.6 sources (using the ToT buildsystem) with
-DCMAKE_BUILD_TYPE=RELEASE -DLIBCXX_ENABLE_SHARED=OFF
-DLIBCXX_ENABLE_STATIC_ABI_LIBRARY=ON and then built the egrep test exactly
like the test-suite normally would. I did the same with the current ToT.

I did see a 10% size of the egrep test but nothing like 2x or 3x.

/Eric

On Sun, Oct 11, 2015 at 3:40 PM, Eric Fiselier <eric at efcs.ca> wrote:

> 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/e573e6c4/attachment.html>