Hi Alon, Thanks a lot. Passing SIDE_MODULE = 2 decreased the size of wasm a lot. But one thing I want to confirm, does something related to this changed with latest backend, because initially I was using SIDE_MODULE = 1, and size of wasm files was okk.
Moreover I want to ask one more thing. As most of the things needs to be passed at compile time with new backend. Do I need to pass EXPORTED_FUNCTIONS=[_someFunction] at compile time too. Regards, On Friday, March 6, 2020 at 4:33:03 AM UTC+5:30, Alon Zakai wrote: > > Thanks Rohit! > > One big difference here is the first has 130 exports while the second has > 1,113. > > For example, JP2KTileComponentSetEncodeOptions (C function) and > _ZN10IJP2KImage16CreateCodeStreamEv (C++ function) are present in the new > one, but not the old one. > > Are those in the list of exported functions? > > From the command above it looks like you're using SIDE_MODULE=1, and not > =2, to build these. If so then it won't DCE away things not in the list of > exports you provide. I'm not sure offhand why that would be different > between the backends though. > > On Thu, Mar 5, 2020 at 4:04 AM Rohit Saini <[email protected] > <javascript:>> wrote: > >> Hi Alon, >> >> Here are the wasm files of one of my side module before (libjp2k.wasm) >> and after (libjp2k_new.wasm) the compiler update. Please tell if you need >> more info from my side. >> >> Regards, >> >> >> >> On Tuesday, March 3, 2020 at 3:15:39 AM UTC+5:30, Alon Zakai wrote: >>> >>> Rohit: Can you perhaps provide the wasm files before and after, built >>> with --profiling? (that flag ensures functions have names) perhaps by >>> comparing them we can find what's gone wrong. >>> >>> On Sat, Feb 29, 2020 at 9:45 AM Rohit Saini <[email protected]> >>> wrote: >>> >>>> 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]> 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/8d6187d7-019e-4191-9d10-ec5e655980f3%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/emscripten-discuss/8d6187d7-019e-4191-9d10-ec5e655980f3%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/144edb11-1b79-49ef-98e5-e220357eb713%40googlegroups.com >> >> <https://groups.google.com/d/msgid/emscripten-discuss/144edb11-1b79-49ef-98e5-e220357eb713%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/dfb54b90-be3a-4b97-b15b-c436fd7ad6b5%40googlegroups.com.
