ErrorOr was added to parts of LLVM after PNaCl / Emscripten were written. Dropping errors doesn't usually speed things up in a measurable way, but it does hinder developer productivity and I'd consider any missing ErrorOr a bug.
Performance of the compiler is much more affected by LTO. On Sun, Jun 14, 2015 at 2:22 PM, chronotext <[email protected]> wrote: > 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. > -- 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.
