Rohit: LTO might be the issue here as others mentioned. Specifically, with the wasm backend, object files are wasm by default. To get LTO you must build the source files with -flto, so that they contain bitcode. (wasm-ld will link both wasm and bitcode files, doing LTO where it can, but not warning if there are no actual bitcode files to LTO with.)
Note that the LLVM versions are quite different, so LTO may behave differently in the new backend. Might be worth trying --llvm-lto 1 instead of 3. Also, might be worth doing -Os (not -O3) during link. Gabriel: That does seem odd. Are you building source files with -flto? Worth checking if the object files are bitcode, as maybe the build system somehow didn't pass the flag through? With that said, I haven't seen great results from LTO on the new backend either. So yeah, maybe something is wrong? I opened https://github.com/emscripten-core/emscripten/issues/10603 for more discussion. On Fri, Feb 28, 2020 at 3:57 AM Gabriel Cuvillier < [email protected]> wrote: > Well, to me LTO *used to* be better. But for some reason, since the > switch to upstream LLVM backend, it is no more very interesting. > > I have been surprised by this, and decided to disable LTO on all my > projects since the switch. But maybe there's a bug lurking somewhere: LTO > is simply not correctly done anymore (?) > > @Emscripten team: any thoughts on this possibility ? or is it simply > because the Wasm backend now does things extremely well ? > Le 28/02/2020 à 12:49, Floh a écrit : > > ...hm ok I did a quick check on my 8-bit emulators, and I have to agree. > I'm seeing about 10% size agree for the generated WASM (which I'd be > willing to eat if the performance would improve too), but performance isn't > any noticeably better. I guess the WASM runtimes either do the inlining > themselves, or can the function call overhead doesn't matter as much as it > used to. > > On Friday, 28 February 2020 12:16:39 UTC+1, Floh wrote: >> >> When I last tested I generally saw quite noticeable improvements for >> inlined code (which LTO does across compilation units). Most of my code is >> straight C without inline functions in headers. I guess this scenario >> benefits more from LTO than typical C++ code where usually a lot of >> implementation code sits in inline/template functions (at the cost of >> increasing compile time for each compilation unit, versus increasing >> link-time once for LTO). >> >> I think it depends extremely on the code base at hand whether LTO is >> useful or not :) >> >> On Friday, 28 February 2020 11:32:09 UTC+1, Gabriel CV wrote: >>> >>> Glad to! >>> >>> By the way, I don't find that LTO brings any performance improvements >>> compared to a non-LTO builds (on latests Emscripten backend). Maybe +1% at >>> most (more probably benchmark noise to me), but sometime more than 10% >>> worse, and at the expense of a *significant *link time increase and >>> *significant >>> *binary size increase! >>> >>> So I am not sure this is really an interesting option anymore... >>> >>> >>> Le 28/02/2020 à 11:14, Floh a écrit : >>> >>> Whoops, thanks for making me aware of WASM_OBJECT_FILES being 1 by >>> default... I've been building with LTO all the time (since the asm.js days) >>> and was expecting that the WASM backend would behave identically there. >>> >>> -Floh. >>> >>> On Friday, 28 February 2020 10:07:11 UTC+1, Gabriel CV wrote: >>>> >>>> Hi, >>>> >>>> Try to remove --llvm-lto 3, as it might increase binary size >>>> significantly when combined with -O2 or -O3 (and I am not sure it is very >>>> usefull without using -DWASM_OBJECT_FILES=0) >>>> Le 28/02/2020 à 08:12, Rohit Saini a écrit : >>>> >>>> Hi All, >>>> >>>> Previously we were using 1.38.28 emscripten version. Recently we >>>> updated to latest llvm backend 1.39.7. But with new backend there is >>>> drastic increase in wasm size. Size of my side modules become almost double >>>> and size of my main module also increased from 2.7mb to almost 4mb. Firstly >>>> we are compiling to object files then we are linking them to make wasm. >>>> Below are the flags I am passing while compiling and linking. Is this size >>>> increase intentional or do I have to change compiling or linking flags >>>> someway. >>>> >>>> Compiling flags for main module: >>>> -Oz -fPIC >>>> -s DISABLE_EXCEPTION_CATCHING=0 -Wno-builtin-macro-redefined >>>> -Wno-dollar-in-identifier-extension >>>> >>>> Compiling flags for side module: >>>> -std=c++14 -fPIC >>>> >>>> Linking flags for main module: >>>> >>>> -O3 -s EVAL_CTORS=0 --closure 0 -s ALIASING_FUNCTION_POINTERS=0 -s >>>> ELIMINATE_DUPLICATE_FUNCTIONS=1 -s ELIMINATE_DUPLICATE_FUNCTIONS_PASSES=12 >>>> --llvm-lto 3 -s FORCE_FILESYSTEM=1 -s ERROR_ON_UNDEFINED_SYMBOLS=0 -s >>>> 'EXTRA_EXPORTED_RUNTIME_METHODS=["getTempRet0","setTempRet0", "cwrap"]' -s >>>> [email protected] >>>> -s DISABLE_EXCEPTION_CATCHING=2 -s >>>> [email protected] >>>> >>>> Linking flags for side module: >>>> -s SIDE_MODULE=1 -s WASM=1 -Oz -s EVAL_CTORS=0 --closure 0 -s >>>> ALIASING_FUNCTION_POINTERS=0 -s ELIMINATE_DUPLICATE_FUNCTIONS=1 -s >>>> ELIMINATE_DUPLICATE_FUNCTIONS_PASSES=12 --llvm-lto 3 -s >>>> ERROR_ON_UNDEFINED_SYMBOLS=0 >>>> -- >>>> 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]. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/emscripten-discuss/5f30a113-7203-4eba-9426-9f626c51ec26%40googlegroups.com >>>> <https://groups.google.com/d/msgid/emscripten-discuss/5f30a113-7203-4eba-9426-9f626c51ec26%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>>> -- >>> 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]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/emscripten-discuss/e8a9f44f-a8f5-46f2-b440-e2356f285d28%40googlegroups.com >>> <https://groups.google.com/d/msgid/emscripten-discuss/e8a9f44f-a8f5-46f2-b440-e2356f285d28%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >>> -- > 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]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/emscripten-discuss/38cfb2aa-6b9c-4dfb-a978-1c9c520d3693%40googlegroups.com > <https://groups.google.com/d/msgid/emscripten-discuss/38cfb2aa-6b9c-4dfb-a978-1c9c520d3693%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > -- > 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]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/emscripten-discuss/2e3a6f1d-869e-06f5-5341-a031aaa8fc09%40gmail.com > <https://groups.google.com/d/msgid/emscripten-discuss/2e3a6f1d-869e-06f5-5341-a031aaa8fc09%40gmail.com?utm_medium=email&utm_source=footer> > . > -- 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]. To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpSMFT6hxMAy%3D5qkMdbsNtsywVD36jaxQNamBj3T%2BUTeYw%40mail.gmail.com.
