incoming branches merged to master / fastcomp-by-default now on master

[Alon Zakai]

Hi everyone,

After several months of development, the new LLVM backend ("fastcomp") is now on the master branch. It has been complete for a few months, but we waited while people tested on the incoming branch before merging it to master. We've also done extensive fuzzing, and Jukka has the bots all green on all platforms, so things now look stable.

See details on the backend at

https://github.com/kripken/emscripten/wiki/LLVM-Backend

I also updated the other wiki pages about installing Emscripten from source, etc, hopefully I got it all, please let me know if I missed anything.

What this change means for you:

1) If you've been using incoming, nothing changes.

2) If you've been using master, then next time you pull, emscripten will have fastcomp on by default. You should get and build Emscripten's LLVM+Clang which has fastcomp, and use that (see instructions in the link above). (You also have the option to disable fastcomp and use a stock LLVM, again details are in the link, but that is not recommended.) After updating to fastcomp, you should see a big speedup in compilation times, especially on large codebases; the generated code should also be a little smaller and faster. Otherwise there should be no differences, however a few features are not yet fastcomp-compatible (like embind), so you may get a compiler warning or error if you use one of those. (If you do, your options are to disable fastcomp as mentioned before, or to use an earlier version of emscripten.)

As mentioned in the title, we now have multiple branches - the main Emscripten repo, our LLVM repo and our Clang repo. See the link above for details. What you need to keep in mind is the 3 repos need to be in sync - make sure to use either the master branch in all 3, or the incoming branch in all 3, as mixing and matching may not work. In particular, if you use master, you will need to pull master in all 3 repos each time you update (and then build LLVM+Clang with those changes), whereas before you just had one repo to pull. You can use

  emcc -v

to check if the source code in the 3 repos have the same version number.

3) If you are using an SDK build, nothing changes. The next SDK update, however, will be built from master, so it will include fastcomp, at which point the changes will be the same as in the last paragraph (as if you were using master). We'll probably wait on releasing the SDK update for a while, to see if any issues are reported on master.

- Alon

[Joshua Litt]

Huge thanks to everyone!  This is really cool, and I am super excited to try fastcomp on my project.

[Seth Hays]

I've noticed that I have had to use the EMCC_FAST_COMPILER=1 even using the incoming branch.  I believe it was mentioned in the wiki that this should be the default behavior.  Is that the case now?

[Alon Zakai]

This is now the default behavior, yes. Verify that your environment doesn't have EMCC_FAST_COMPILER=0 in it for some reason; if that's not it we need to figure out what's wrong.

- Alon

On Wed, Apr 16, 2014 at 4:50 PM, Seth Hays <hays...@gmail.com> wrote:

I've noticed that I have had to use the EMCC_FAST_COMPILER=1 even using the incoming branch.  I believe it was mentioned in the wiki that this should be the default behavior.  Is that the case now?

--
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 emscripten-disc...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ryan Sturgell]

Very exciting! Do you have any sense of how long it will take to upstream the llvm/clang changes?

Thanks,

Ryan

On Wednesday, April 16, 2014 11:37:04 AM UTC-7, Alon Zakai wrote:

[Alon Zakai]

First we'll make sure things are stable, especially after the new backend goes out in the SDK (which it hasn't yet in a non-beta version). Then we can discuss more details with upstream. So it will take a while, hard to say how much, it will depend mostly on upstream LLVM's decisions.

- Alon