Hi, It looks like LLVM fastcomp is not throwing exceptions internally (cf the ErrorOr construct <https://github.com/kripken/emscripten-fastcomp/blob/1.32.4/include/llvm/Support/ErrorOr.h>, etc.), which is supposed to enhance Emscripten's performance.
Can it be considered as another good reason to favour fastcomp over the "regular" LLVM version? On Saturday, June 13, 2015 at 7:01:37 PM UTC+3, [email protected] wrote: > > Hi! > > ever since I've learned that current Emscripten depends on a custom branch > of LLVM, I've been wondering about this. > > - What changes make the Emscripten branch different from upstream? > - Why are those changes necessary? > - Which of these changes are necessary at compile time, and which at > link time? > - Is the plan to keep this split, or to unify things back again? > - What does NaCl have to do with all of this? > > I know the answers to my questions are somewhere out there, but digging > through tons of mails for that doesn't feel very rewarding. Is there some > kind of documentation for all of this? If so, feel free to answer all of my > questions with a simple link to that documentation. > > I've started answering my first question: what changed? Looking at the > most recent merge from LLVM upstream through NaCl into Emscripten, I see > changes > by NaCl to 694 files > <https://github.com/kripken/emscripten-fastcomp/compare/02916381eb87518ba6d541b065141a72b60561da...ce5573729064e6e54e1c05e1f5e5bd0a65fc6fe8#files_bucket>, > > and changes by Emscripten to 42 files > <https://github.com/kripken/emscripten-fastcomp/compare/ce5573729064e6e54e1c05e1f5e5bd0a65fc6fe8...78afe0bb182d056d5d5e24894c3f66e5b6fe0c7f#files_bucket>. > > The former is too much for GitHub to display, but after filtering the list > of affected files, I see things like the newly introduced > lib/Target/JSBackend > <https://github.com/kripken/emscripten-fastcomp/tree/ce5573729064e6e54e1c05e1f5e5bd0a65fc6fe8/lib/Target/JSBackend> > > directory. That directory is mostly authored by Emscripten developers, as > far as I can see. So does that mean that the NaCl project integrated the > Emscripten codebase into their own? I thought they were shipping LLVM IR to > be executed by Chrome without detour through a JavaScript implementation. > The changes to Emscripten which are not included in NaCl are many commits > but few modifications, so is that just stuff NaCl hasn't merged into their > code yet? So far I haven't found a merge from Emscripten to NaCl yet, but > that's probably because I can't think of the correct git commands to ask > for this, and the graph is just too big for manual scrolling. > > The clang repository shows a similar picture on a smaller scale. Upstream > to NaCl > <https://github.com/kripken/emscripten-fastcomp-clang/compare/8eceb42a00eee3f45ff5e3c8665c32e4ac9feeb4...097061e2dec7091d5256f0e80909bf1641087b97#files_bucket> > > shows changes to 30 files, many of them mentioning Emscripten. The changes > from that to Emscripten > <https://github.com/kripken/emscripten-fastcomp-clang/compare/097061e2dec7091d5256f0e80909bf1641087b97...6bef7274efd0513418674ce0f215c46d188957da#files_bucket> > > are almost negligible. This time, however, the commits to the NaCl repo are > by people I haven't noticed as core Emscripten contributors before. Are > they? If not, what is the motivation for adding Emscripten-specific code > there? > > As to why all these changes are necessary: I assume that a C++-written > backend is “obviously” the fastest way to generate target-specific code > from IR. I'd have assumed that it should be possible to implement such a > backend as a plug-in, or as a separate program linking against the LLVM > libs. Why hasn't that been done, but the source tree been modified instead? > Is it because that's simply the easiest way to ensure all versions and > paths and stuff match up? Or is it because this should end up in vanilla > LLVM one day, so it might as well be written to that code tree and kept in > sync with it? Or is vanilla LLVM simply not flexible enough to allow for > such a backend without modifications to other places as well? > > The distinction between compile time and link time is particularly > important when dealing with other front ends. What if I want to compile > Fortran, D, or any other language to JavaScript? Is it enough to generate > LLVM code using any frontend, and feed that to Emscripten? Can I safely > ignore the warning that I'm linking IR code generated for different > triples? Or should I try to compile each such frontend against the LLVM > library? Would that even be enough, or are the modifications to clang > essential enough that compiling other languages this way would be > problematic? (I've recentry investigated ways to compile LAPACK > <https://github.com/kripken/emscripten/issues/998#issuecomment-110954873> > using Dragonegg <http://dragonegg.llvm.org/>, and even though Dragonegg looks > pretty much dead > <https://github.com/llvm-mirror/llvm/commit/3d09e0e55093ecb569a5c700> and > flang <https://github.com/isanbard/flang> still a fetus, I wonder whether > this could work for more than the single example function I've tried so > far. My first contributions > <https://github.com/kripken/emscripten/pull/841> to Emscripten where when > I tried to feed ldc output to it, and I'm still interested in compiling D > to JavaScript.) > > The question of whether Emscripten changes will (aim to) be merged into > llvm has been raised on this list before > <https://groups.google.com/d/msg/emscripten-discuss/_kIjDA3oKDY/U4UsxyIhBPcJ>, > > but the response only talked about rebasing, which isn't the same thing as > I see it. Are there plans to one day have all the JS-specific changes in > vanilla LLVM, and to have Emscripten simply compile against that? If not, > is some alternative like a plugin or similar envisioned? Having multiple > copies of LLVM lying around doesn't feel good in the very long term. > > I hope my curiosity hasn't annoyed anyone too much. Thanks for reading, > and thank you even more for any insights you can provide. > > Greetings, > Martin von Gagern > > > -- 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]. For more options, visit https://groups.google.com/d/optout.
