Yeah, I'm not sure if that would help much or not. I guess another option could be to just make everything work at compile time and then pass the flags through the object files similarly to what we do with target features. That would be convenient for build systems (all the flags in one place). Then we'd have to reason about what happens when object files disagree (but that would also be an opportunity to catch mismatches in cases where that matters)
On Fri, Oct 25, 2019 at 10:19 AM Alon Zakai <[email protected]> wrote: > > > On Fri, Oct 25, 2019 at 9:54 AM 'Derek Schuff' via emscripten-discuss < > [email protected]> wrote: > >> This is a good point, actually. Before, almost all of the >> emscripten-specific flags only mattered at link time, and now there are >> probably several that also matter at compile time. We should probably take >> a pass over the docs and figure that out, or else just declare that >> everything should also go at compile time. >> > > The docs have recently been update to say that it is best (search for > "simple and safe") to pass the flags at both times, > > https://emscripten.org/docs/compiling/WebAssembly.html#backends > > But maybe that's not prominent enough? > > I can do a pass through settings.js to mark options as "link" or "compile" > if that would help? Not sure it would. > > - Alon > > > Emscripten is already a little weird that so many things matter at link >> time so I think the default expectation of most users (and build systems) >> would be that you only have to pass things at compile time. It would be >> nice to push the upstream backend more in that direction rather than going >> back. >> >> On Fri, Oct 25, 2019 at 5:31 AM Gabriel Cuvillier < >> [email protected]> wrote: >> >>> Ok, I understand better. >>> >>> What makes things confusing is probably more that the usual distinction >>> between compiler flags and linker flags are a bit blurred in Emscripten. >>> >>> As "WASM_OBJECT_FILES=0" is doing the same as "-flto", but also applying >>> it to system libs, maybe it would be cleaner to have it replaced by a "-s >>> ENABLE_SYSTEM_LIBS_LTO=1" that would only focus on enabling LTO on the >>> system libs (letting the user control the LTO of its own code with the >>> usual -flto flag). >>> >>> >>> Btw, the docs mention that --lvm-lto might have the values 1,2 or 3 => >>> is this still applicable to the new Wasm backend ? I guess no (?) >>> >>> Cheers, >>> >>> Gabriel >>> >>> Le 22/10/2019 à 21:39, Alon Zakai a écrit : >>> >>> The LTO docs are here: >>> >>> https://emscripten.org/docs/optimizing/Optimizing-Code.html#lto >>> >>> Basically >>> >>> * -flto is a clang flag that says "emit LLVM IR in the bitcode file" >>> * WASM_OBJECT_FILES=0 is an emscripten flag that says "don't use wasm >>> object files, so use LLVM IR in bitcode files, *and also in system libs*" >>> * --llvm-lto 1 is an emscripten flag that also runs LLVM's default LTO >>> opts at link time. >>> >>> Perhaps -flto should automatically set --llvm-lto 1? I'm not sure what >>> clang normally does, but we should do the same probably... >>> >>> - Alon >>> >>> >>> On Tue, Oct 22, 2019 at 2:40 AM Gabriel Cuvillier < >>> [email protected]> wrote: >>> >>>> Great! >>>> >>>> A question regarding this in the documentation, which confuses me a bit: >>>> >>>> *You can disable wasm object files with -s WASM_OBJECT_FILES=0, which >>>> will make the wasm backend behave more like fastcomp. * >>>> *Neither fastcomp nor the wasm backend without wasm object files will >>>> run the LLVM optimization passes by default, even if using LLVM IR in >>>> object files; * >>>> *for that you must pass --llvm-lto 1.* >>>> >>>> With the 3 options "-s WASM_OBJECT_FILES=0", "--llvm-lto 1", and >>>> "-flto", there is a lot of combinations possible and the outcome is not >>>> quite clear. >>>> >>>> So, on the Wasm backed, what's the difference between doing (or what is >>>> meaningful/meaningless): >>>> -flto >>>> --llvm-lto 1 >>>> -s WASM_OBJECT_FILES=0 >>>> -flto --llvm-lto 1 >>>> -flto -s WASM_OBJECT_FILES=0 >>>> -flto -s WASM_OBJECT_FILES=0 --llvm-lto 1 >>>> -s WASM_OBJECT_FILES=0 --llvm-lto 1 >>>> >>>> + Which option shall be passed at compilation time / at link time ? >>>> >>>> Thanks! >>>> Le 22/10/2019 à 00:17, Alon Zakai a écrit : >>>> >>>> Hello everyone, >>>> >>>> The emsdk will now install the upstream LLVM backend by default, >>>> instead of fastcomp, as of >>>> >>>> https://github.com/emscripten-core/emsdk/pull/373 >>>> >>>> That is, if you install/activate "latest" then you get the same as >>>> "latest-upstream". It used to be an alias for "latest-fastcomp". >>>> >>>> You can still use "latest-fastcomp" to get fastcomp if you need that. >>>> You can also install stuff like "1.39.0-fastcomp", a version with a >>>> specific backend. >>>> >>>> The emsdk defaults to the upstream backend from 1.39.0, but not earlier >>>> versions, as the upstream backend wasn't stable enough yet at those times. >>>> (But you can as always do "1.38.39-upstream" to get upstream for those >>>> versions.) In other words, the only thing that changed now is that for >>>> 1.39.0 and onwards, if you don't specify the backend, you'll get upstream. >>>> >>>> We are changing the default now after a long period of recommending >>>> people upgrade to the LLVM backend and fixing issues based on their >>>> feedback, as a result of which at this point we feel comfortable changing >>>> the default. >>>> >>>> Please test and file bugs if you find any! All you need to do is update >>>> to the latest emsdk master from github, and >>>> >>>> ./emsdk install latest >>>> ./emsdk activate latest >>>> >>>> If this is your first time using the upstream backend, see the list of >>>> differences, >>>> >>>> https://emscripten.org/docs/compiling/WebAssembly.html#backends >>>> >>>> Our goal is to remove fastcomp eventually, and it is now officially >>>> deprecated, but we will only start to plan that after seeing the feedback >>>> from users after this switch. >>>> >>>> - Alon >>>> >>>> -- >>>> 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/CAEX4NpTHC%3DRz2UZrqLBBaPQ0ROT4JXGA7RnH5iDEsLeUdvRmMA%40mail.gmail.com >>>> <https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpTHC%3DRz2UZrqLBBaPQ0ROT4JXGA7RnH5iDEsLeUdvRmMA%40mail.gmail.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/06858de5-a732-0e70-6ce7-e60c1a9e2667%40gmail.com >>>> <https://groups.google.com/d/msgid/emscripten-discuss/06858de5-a732-0e70-6ce7-e60c1a9e2667%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/CAEX4NpRXtK1wYBfm27dqgALwr2oHMZLE4QeU7rN1KKEugfORfg%40mail.gmail.com >>> <https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpRXtK1wYBfm27dqgALwr2oHMZLE4QeU7rN1KKEugfORfg%40mail.gmail.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/24154c49-5529-af52-1319-c0cd47ccb242%40gmail.com >>> <https://groups.google.com/d/msgid/emscripten-discuss/24154c49-5529-af52-1319-c0cd47ccb242%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/CAAEAhvckhm4szfJzz61wa7jMAHyDfbhozjDw8-GFCXa3dh4R%3Dw%40mail.gmail.com >> <https://groups.google.com/d/msgid/emscripten-discuss/CAAEAhvckhm4szfJzz61wa7jMAHyDfbhozjDw8-GFCXa3dh4R%3Dw%40mail.gmail.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/CAEX4NpTOyCC%2BF0i7zrQNPFWW3nFim7c%3DntgUxKU4uPhbHs3NKg%40mail.gmail.com > <https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpTOyCC%2BF0i7zrQNPFWW3nFim7c%3DntgUxKU4uPhbHs3NKg%40mail.gmail.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/CAAEAhvdi3pEZ4OM-5%3DkMEyU8Tr4PO8i317RjThYWsvYZdy%3DZtQ%40mail.gmail.com.
