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]. To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpR4ururapAdFMgRxHOpeA917HsEuXXsknQaKp4pYz%3DhLA%40mail.gmail.com.
