I'm not a member of the emscripten team, but here's my outside view: I think when emscripten started with the 'fastcomp' LLVM-backend approach (as opposed to the custom IR-to-JS translator written in JS used before), the work already done by the NaCl team was a good base for emscripten's own code generation backend, because the NaCl backend already lowered the LLVM IR in a way emscripten (or at least asm.js?) needed.
So basically, similar requirements would have led to similar solutions, but since NaCl already provided the solution, and both projects are open source, it made sense to not reinvent the wheel. I'm not sure what the current state is of getting the changes accepted upstream, I think the current approach (2 technologies sharing most modifications) have a better chance to be accepted then if each would do their own thing. Personally I don't find it a problem that each SDK has its own compiler(s), since everything is completely isolated (or at least can be set up this way), and it's also quite common that cross-compiling SDKs come with their own compilers included (e.g. Android, NaCl, game console SDKs, etc...). Cheers, -Floh. Am Samstag, 13. Juni 2015 18:01:37 UTC+2 schrieb [email protected]: > > 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.
