<div dir="ltr">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.<div><div><div><br><div>Originally I thought it might be related to the external instantiations of std::basic_string,</div><div>but nothing should have changed between 3.6 and 3.7 in that regard. </div><div><br></div><div>> Are there any ways of building the library with minimal or no locale support?</div><div><br></div><div>No and I don't think libc++ should add one. We already support way to much</div><div>feature sub-setting. </div><div><br></div><div><div><br></div><div><br></div><div>/Eric</div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Oct 11, 2015 at 6:34 AM, Martin J. O'Riordan via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi CFE Devs,<br>
<br>
I have recently completed upgrading our CLang/LLVM based compiler from v3.6<br>
to v3.7, but I was noticing some significant regressions in the LibC++<br>
test-suite.  Something has changed that is resulting in the code-size being<br>
about 3X larger and the data size being about 2.7X larger.<br>
<br>
Initially I suspected the compiler was at fault, so I did a series of builds<br>
and comparisons to narrow down where the problem changes occurred.  I'll<br>
take one test as an example:<br>
<br>
   projects/libcxx/test/std/re/re.alg/re.alg.search/egrep.pass.cpp<br>
<br>
With the v3.6 compiler and the v3.6 LibC++ library, this test was resulting<br>
in a program with 122,916 Bytes of code and 6,240 Bytes of data.  With the<br>
v3.7 compiler and the v3.7 LibC++ this became 366,708 and 16,680<br>
respectively!  I don't know how this compares with other targets, so I can<br>
only discuss our SHAVE program size.<br>
<br>
At first I thought that perhaps we had broken something in LLVM, inlining<br>
for example, so I tried the following:<br>
<br>
   Use the v3.7 compiler to run the tests, but with the v3.6 built LibC++<br>
   library and v3.6 LibC++ headers.  This brought the figures to 127,940<br>
   and 6,240 respectively; much closer to the original.<br>
<br>
But this still didn't rule out a fault in the compiler.  So I tried the<br>
following:<br>
<br>
   Use the v3.7 compiler to build the v3.6 LibC++ library, and again run<br>
   the tests using this library and the v3.6 LibC++ headers.  This time I<br>
   got 127,940 and 6,288 Bytes respectively; very close to the v3.<br>
   compiler figures which would indicate that the compiler itself has not<br>
   caused this regression.<br>
<br>
So I am wondering what has happened in the sources for LibC++ v3.7 that<br>
could cause this?<br>
<br>
What appears to be happening, is that the library is pulling in many more<br>
symbols (hundreds) from the libraries even though they are never actually<br>
executed, and a lot of these are related to 'char_traits' and<br>
wide-characters; especially in the streams and stream iterators.  I haven't<br>
previously delved into the sources for the LibC++ library as my primary<br>
focus is on the compiler (backend mainly), so I don't have enough experience<br>
of the implementation of LibC++ to determine why this is.  Examining the<br>
header changes doesn't reveal any obvious smoking gun, though I did notice<br>
that there are some significant 'traits' related changes to '<streambuf>'.<br>
<br>
Our platform is for embedded deployment, so I we don't need rich locale<br>
support (C locale is fine), nor Unicode or wide-characters.  But I don't see<br>
any configuration options in the sources for LibC++ that allows these to be<br>
tuned for embedded systems.  Are there any ways of building the library with<br>
minimal or no locale support?<br>
<br>
We build LibC++ as a static library with RTTI enabled, but with threads and<br>
exception handling disabled ('__SINGLE_THREAD__', '_LIBCPP_NO_EXCEPTIONS',<br>
'_LIBCPP_BUILD_STATIC', '_LIBCPP_HAS_NO_THREADS' and<br>
'_LIBCPP_HAS_NO_MONOTONIC_CLOCK' are all defined).<br>
<br>
For LibC we are using Newlib v2.2.0, and our assembler does not support weak<br>
externals which might be relevant, but we do support ODR linkage and garbage<br>
collection in the linker (all data & functions in discrete sections).<br>
<br>
Is anybody else experiencing this kind of size increase in C++ programs<br>
since migrating to v3.7?  I have 507 LibC++ v3.7 test-cases which have<br>
similarly increased versus the v3.6 version, mostly in the area of iterators<br>
and streams.<br>
<br>
Thanks,<br>
<br>
        MartinO - Movidius Ltd.<br>
<br>
<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div><br></div></div></div></div></div></div>