Hi Alon, I tried removing -llvm-lto 3 and used -Os while linking, but still there is no change in size. Trying --llvm-lto 1 didn't help either.
Regards, Rohit Saini On Saturday, February 29, 2020 at 3:27:58 AM UTC+5:30, Alon Zakai wrote: > > 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] > <javascript:>> 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] <javascript:>. >> 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] <javascript:>. >> 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/8d6187d7-019e-4191-9d10-ec5e655980f3%40googlegroups.com.
