I was expecting that it rebuilds if the source code has changed, but you're right, in this case it is better to keep this as it is (e.g. only rebuild after a 'emcc clear-cache').
I'm not sure whether an automatic removal will work, since something cin/cout-related seems to trigger the inclusion of that big chunk of code, and that's why it is included in the first place, and not removed by dead-code-removal. For instance, just building a simple printf-hello-world program as C++ code will not include those additional 300kByte code, only when explicitely using cout << "Hello World" (the difference I'm seeing with a simple 'emcc -O2 hello.cc -o hello.html' is 158kByte with printf vs 552kb with cout). But in my more complex engine code I'm not using cin/cout anywhere in my own code yet the cin/cout init code is included when linking, so I'm thinking it is another part of the standard lib which causes the inclusion. Some unrelated std C++ header is probably using cout in case of an error, and if this error would be triggered an exception would be thrown because the std streams have not been initialized. I think if emscripten would try to remove this init code automatically it would have to do this despite there being 'valid' references to cin/cout in the code. On the other hand if the init code is left out during the libcxx compilation by embuilder.py it would tweakable per project (some projects might require cin/cout, some not), and this is where an embuilder param would be handy (I agree that just passing through any flags to the compiler directly might not be a good idea). Instead it could be like one of those 'dangerous' -s emcc flags, but for embuilder, e.g. "embuilder.py build libcxx -s FORCE_NO_STDSTREAMS=1", this would be off by default, and if switching it on you'll have to know what you're doing, since any use of cin/cout will crash. embuilder could also store in the cache the last build settings, so that it knows when it needs to rebuild because the settings flags have changed. Of course removing the code during an LLVM pass might be the better option, I don't know the internals well enough to judge :) Cheers, -Floh Am Montag, 29. Dezember 2014 22:25:37 UTC+1 schrieb Alon Zakai: > > Currently embuilder will only build if necessary - so it is safe to run > multiple times in succession, without doing extra work. Perhaps though this > is not the most natural thing - looks like you were expecting it to always > build when requested? > > We could allow it to receive flags that it passes on to the things being > built, but then we'd need to handle configure flags, env flags, etc., and > maybe something else I'm forgetting? What then worries me is someone > building with a special flag, and forgetting that, and then their system > lib can cause problems later. If you manually build it to a non-system > location that seems less likely to confuse. > > Regarding the significant code size shrinkage you saw when removing that > iostream line, I wonder if we can figure out an LLVM pass to do it > automatically? Clearly right now LLVM's dead code elimination isn't > managing to remove that code, but maybe we can improve it, or add hinting > or something like that. It would be helpful to try to reduce the iostream > case to something standalone that shows the same issue, so we know what to > focus on. But if that's hard to do, I can look at libc++ directly. > > - Alon > > > On Thu, Dec 25, 2014 at 6:26 AM, Floh <[email protected] <javascript:>> > wrote: > >> I think the best solution would be to allow embuilder.py to accept >> preprocessor defines (or may be even general compiler/linker cmdline args >> which are forwarded), e.g.: >> >> ./embuilder.py build libcxx -- -DBLABLA=1 >> >> Then there could be a set of standard defines which switch on/off certain >> features in the libs built by embuilder.py >> >> In our own build systems, we could then add embuilder.py as a >> pre-built-step with specific preprocessor defines...? >> >> Cheers, >> -Floh. >> >> Am Mittwoch, 24. Dezember 2014 14:41:03 UTC+1 schrieb Floh: >> >>> I think a complete modularisation isn't necessary, since most static lib >>> code should only be pulled in if used. >>> >>> The biggest 'cheap' gain comes from removing a single line of code in >>> libcxx/iostream.cpp where a static object is constructed to initialize the >>> iostream system: >>> >>> // ios_base::Init __start_std_streams; >>> >>> This is a hack of course, I don't know what would happen if my code >>> would try to call iostream stuff, but the size savings are quite >>> dramatical, about 350kByte (uncompressed) on the JS files, for the (quite >>> small) Oryol demos, this is really a big win: >>> >>> 713102 -> 360222 Clear.js >>> 473029 -> 119561 CoreHello.js >>> 1068208 -> 770951 DDSCubeMap.js >>> 1070180 -> 773362 DDSTextureLoading.js >>> 814544 -> 489893 DebugText.js >>> 962358 -> 666109 DrawCallPerf.js >>> 780651 -> 427877 FullscreenQuad.js >>> 970307 -> 673521 GPUParticles.js >>> 535236 -> 182208 HTTPClientSample.js >>> 643000 -> 347095 IOQueueSample.js >>> 923865 -> 602929 InfiniteSpheres.js >>> 963751 -> 667261 Instancing.js >>> 925094 -> 604076 PBRendering.js >>> 901544 -> 580764 PackedNormals.js >>> 928600 -> 627626 Paclone.js >>> 941672 -> 645518 Sensors.js >>> 901762 -> 580639 Shapes.js >>> 920948 -> 600069 SimpleRenderTarget.js >>> 908263 -> 608208 SynthTest.js >>> 967160 -> 671005 TestInput.js >>> 1383053 -> 1098855 TestNanoVG.js >>> 871810 -> 574982 TextureFloat.js >>> 842690 -> 493159 Triangle.js >>> 948571 -> 652293 VertexTexture.js >>> 446748 -> 85235 hello.js >>> >>> The .mem files are reduced by about 14kByte (uncompressed): >>> >>> 42776 -> 28552 Clear.html.mem >>> 16616 -> 2376 CoreHello.html.mem >>> 82736 -> 69288 DDSCubeMap.html.mem >>> 83368 -> 69920 DDSTextureLoading.html.mem >>> 70864 -> 56640 DebugText.html.mem >>> 77352 -> 63904 DrawCallPerf.html.mem >>> 57040 -> 42816 FullscreenQuad.html.mem >>> 89592 -> 76144 GPUParticles.html.mem >>> 30712 -> 16480 HTTPClientSample.html.mem >>> 42808 -> 29352 IOQueueSample.html.mem >>> 65296 -> 51168 InfiniteSpheres.html.mem >>> 77280 -> 63832 Instancing.html.mem >>> 82224 -> 68096 PBRendering.html.mem >>> 63040 -> 48912 PackedNormals.html.mem >>> 222536 -> 208992 Paclone.html.mem >>> 77160 -> 63712 Sensors.html.mem >>> 63008 -> 48880 Shapes.html.mem >>> 66368 -> 52240 SimpleRenderTarget.html.mem >>> 80096 -> 66552 SynthTest.html.mem >>> 80160 -> 66728 TestInput.html.mem >>> 74576 -> 61408 TestNanoVG.html.mem >>> 79784 -> 66336 TextureFloat.html.mem >>> 60576 -> 46448 Triangle.html.mem >>> 83800 -> 70352 VertexTexture.html.mem >>> 15160 -> 544 hello.html.mem >>> >>> By the way, I currently have to manually delete the libcxx.bc file from >>> .emscripten-cache before embuilder.py actually recompiled the lib after >>> changing the source code. >>> >>> I'll play around with this a bit more over the next days and try to find >>> a clean solution. If it is possible to easily link a non-standard libcxx, >>> may be the best solution would be to compile 2 libcxx, the standard one >>> with iostream, and a 'libcxx_no_iostream.bc' without the iostream >>> initialization. >>> >>> It would be good though to get a linker error when the user code tries >>> to use iostream functionality... >>> >>> I'm also not sure whether this should be an official emscripten feature >>> at all, if it remains a 'hack' which is not really C++ compatible, then it >>> is may be better to treat this as a size-optimization trick and only put a >>> how-to into the emscripten docs? >>> >>> Cheers (and merry christmas), >>> -Floh. >>> >>> Am Freitag, 19. Dezember 2014 22:57:23 UTC+1 schrieb Alon Zakai: >>>> >>>> Well, the issue there is that we would need to refactor libc++ into >>>> modules, or something like that? Or add ifdefing to libc++. Unless there >>>> is >>>> a better way that I can't think of. >>>> >>>> The system builder tool just offers a way to ask for a system component >>>> to be built, it currently can't do anything the system couldn't already do. >>>> >>>> But, if we find a way to modularize libc++, then an option for the >>>> system builder would indeed be the right place to put it. >>>> >>>> - Alon >>>> >>>> >>>> On Fri, Dec 19, 2014 at 1:25 PM, Floh <[email protected]> wrote: >>>>> >>>>> Will this allow is to build libc++ without iostream constructors as >>>>> discussed earlier? (https://github.com/kripken/emscripten/issues/2785) >>>>> >>>>> Cheers, >>>>> -Floh. >>>>> >>>>> Am Donnerstag, 18. Dezember 2014 23:33:20 UTC+1 schrieb Alon Zakai: >>>>> >>>>>> I pushed to incoming a "system builder" tool, embuilder.py It lets >>>>>> you manually ask that things be built, like libc, the native optimizer, >>>>>> zlib from ports, etc. >>>>>> >>>>>> embuilder.py -help shows the available operations. >>>>>> >>>>>> This addresses part of the requests for a more manual way to build >>>>>> things from emscripten ports. It also allows other manual building, >>>>>> which I >>>>>> have heard some projects have been doing, of things like libc, etc. >>>>>> >>>>>> For example, you might do this: >>>>>> >>>>>> ./embuilder.py build zlib >>>>>> ./emcc code.cpp -s USE_ZLIB=1 >>>>>> >>>>>> and the first command will already ensure that zlib is fetched and >>>>>> built. >>>>>> >>>>>> Thoughts? >>>>>> >>>>>> - Alon >>>>>> >>>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "emscripten-discuss" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> -- >> You received this message because you are subscribed to the Google Groups >> "emscripten-discuss" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
