Yes, I guess you are right. It is is probably very code-dependent, and for raw C code LTO have a lot more sense than for complex C++ code with crazy template magic.

Le 28/02/2020 à 12:16, Floh a écrit :

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]
    <javascript:>.
    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/a753d986-3f0a-45e1-8acd-3bb6a363fcd6%40googlegroups.com <https://groups.google.com/d/msgid/emscripten-discuss/a753d986-3f0a-45e1-8acd-3bb6a363fcd6%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/b005bdff-4e8c-90bb-dd1e-e998560f495b%40gmail.com.

Reply via email to