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]
<mailto:[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.
