For removing C++ bloat you could try duplicate function elimination <https://github.com/kripken/emscripten/blob/1.36.14/src/settings.js#L714>. But since your problem seems to be specifically around global intialisers, have you tried evaluating global constructors at compile time <https://github.com/kripken/emscripten/blob/1.36.14/src/settings.js#L724>?
For general code slimming, you can try dead functions <https://github.com/kripken/emscripten/blob/1.36.14/src/settings.js#L567> which marks functions to be eliminated from the final asm.js output. I believe this is basically what Alon mentioned with "add a pass to emscripten to remove functions, but that would be after dce though" except it already exists :) Because it runs after DCE, you'd have to hunt down the functions to kill yourself. On 8 November 2016 at 03:14, 'Ben Vanik' via emscripten-discuss < [email protected]> wrote: > Ah interesting! That sounds like a much less hacky way of doing things, > and I'll give it a shot! Thank you! > > On Mon, Nov 7, 2016 at 5:40 PM, Alon Zakai <[email protected]> wrote: > >> Sorry, there isn't a supported way to do that. The closest is >> llvm-extract but it does the opposite (leaves only the stuff you want, >> instead of removing it). With not too much work we could add a pass to >> emscripten to remove functions, but that would be after dce though. >> >> Adding libcxx variants worries me about complexity. Overall, I'd guess >> the best alternative to that is to just grab the string headers and code >> from libc++ and hack on them at the source level to get exactly what you >> want, then build with that. The system libc++ won't be linked in in that >> case (it's only linked in when symbols are unresolved that it provides). >> >> On Mon, Nov 7, 2016 at 4:07 PM, 'Ben Vanik' via emscripten-discuss < >> [email protected]> wrote: >> >>> Thanks for the response! >>> >>> Hmm yeah, without changes to libc++ it sounds tricky... :( >>> >>> Is there a way to blacklist or replace symbols during linking in >>> emscripten? I can of course hack things, but using a supported hack would >>> be nice if it existed :) >>> >>> I ask because I've been fiddling and by just commenting out the contents >>> of ios_base::Init (https://github.com/kripken/em >>> scripten/blob/master/system/lib/libcxx/iostream.cpp#L38) that sets up >>> cin/cout/etc (that I never use) my closure-optimized/gzipped binary went >>> from 308K to 237K (!). If I could - at link time - substitute that function >>> (and a few others) it may be enough to get down to a reasonable size. >>> >>> The other way I see would be to change system_libs.py to add >>> a create_libcxx variant that excludes some of this via preprocessor defines >>> (similar to how DISABLE_EXCEPTION_CATCHING works). Would a DISABLE_STDIO be >>> an interesting PR? >>> >>> On Mon, Nov 7, 2016 at 1:51 PM, Alon Zakai <[email protected]> wrote: >>> >>>> Yeah, any c++ standard library feature can lead to a large increase in >>>> code size, as it ends up linking in big parts of libc++. >>>> >>>> Optimally, it would be nice if upstream libc++ were refactored to avoid >>>> that, but I have no idea how feasible that would be both technically and >>>> not. >>>> >>>> Alternatively, you can use your own custom String class instead of >>>> std::string. You can then make sure it doesn't handle locales and the other >>>> complexity that causes big parts of libc++ to get lumped in. >>>> >>>> Otherwise, some compiler opts might help. On a hello world using an >>>> std::string and -Os, I see 91K output (similar to you). With --closure 1 I >>>> see 72K (at the cost of a slower build time) and with --closure 2 I see 66K >>>> (at the cost of both slower build time and slower runtime as it disables >>>> asm.js). >>>> >>>> Longer-term, wasm will help here. I see the compiled code in that >>>> format is 30K (however, we currently disable minifying the JS part, which >>>> we need to fix). >>>> >>>> >>>> On Mon, Nov 7, 2016 at 1:18 PM, 'Ben Vanik' via emscripten-discuss < >>>> [email protected]> wrote: >>>> >>>>> My resulting asmjs outputs are massive and it's making me sad! I've >>>>> tracked most of the size down to ios_base's global initializer (and the >>>>> world that it pulls in) -- even though I'm not using iostream (or really >>>>> much of anything) and was wondering if anyone had a way to get around >>>>> this. >>>>> >>>>> My hello world sample compiles to 6KiB, but if I include <string> and >>>>> add a single `std::string foo;` it jumps up ~100KiB (even in -O2 with >>>>> --llvm-lto 1). >>>>> The big difference in output comes down to this: >>>>> ``` >>>>> function __GLOBAL__I_000101() { >>>>> var label = 0, sp = 0; >>>>> sp = STACKTOP; >>>>> __ZNSt3__18ios_base4InitC2Ev(0); >>>>> return; >>>>> } >>>>> + a billion functions called by ios_base::Init. >>>>> ``` >>>>> >>>>> That ios_base::Init pulls in locale and a bunch of other stuff that is >>>>> only ever called from that stack. Because it's a global initializer >>>>> dead-code removal won't get rid of it and it ends up in my final output. >>>>> It >>>>> seems a bit silly that even when not using iostream >>>>> (cin/cout/strstream/etc) I still take a massive hit. >>>>> >>>>> I found this issue from a year or so ago which seems like exactly what >>>>> I'm seeing: >>>>> https://github.com/kripken/emscripten/issues/2545 >>>>> >>>>> Unfortunately the fix proposed never made it in: >>>>> https://github.com/kripken/emscripten/pull/3308 >>>>> >>>>> Besides not using std::string anywhere (which is extremely difficult >>>>> given the code I'm compiling) has anyone found solutions for removing this >>>>> bloat? Is there any emscripten features (in-progress or planned) that will >>>>> help situations like this? >>>>> >>>>> -- >>>>> 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]. >>>> 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. >>> >> >> -- >> 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]. > 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.
