New "fastcomp" LLVM backend about to be turned on in incoming branch

[Alon Zakai]

The last missing features for fastcomp

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

have landed, namely indirect branches, better function pointer error messages, bindings generator support, gl emulation support, and other stuff. At this point everything that the old compiler could do, **and is not deprecated or considering a rewrite**, is functional and enabled in the test suite.

There are various deprecated features like non-typed arrays support, various settings.js options like HEAP_INIT, etc., which will not be ported to fastcomp. The old compiler will remain an option for those.

Perhaps the biggest missing thing is linking support. This is not deprecated, but there are some issues with it - it works on C code, but C++ can break it. For that reason we may want to reconsider our linking approach, so there is no point adding that to fastcomp before doing so. Also, linking is less crucial for fastcomp anyhow - linking has been a way to avoid rebuilding big projects, but fastcomp is fast enough to rebuild entire projects anyhow, and full rebuilds will give more optimal results due to the compiler seeing all the code together and putting it all in one asm.js module.

The plan forward is something like this:

0. Merge master to incoming one last time with fastcomp not yet on by default. That will probably be tagged version 1.8.

1. Land some misc stuff on incoming for fastcomp: change the test suite to run it by default, with some amount of old compiler testing still on, add warnings in case people do not have the proper LLVM build, etc.

2. Enable fastcomp by default on the incoming branch and tag version 1.9.

3. Get feedback and fix bugs on incoming. This will take an uncertain amount of time, during which no merges to master will occur.

4. Merge to master when things are deemed stable and tag version 2.0.

5. Further testing and fixes (as the code has reached a larger range of users).

6. juj will make SDK builds with the new stable version of emscripten which will contain fastcomp.

Please let me know about any thoughts or concerns about this plan.

- Alon

[Chad Austin]

To anyone who's curious: note that embind does not currently work on fastcomp.  To make it work, we will need to rework a few things, mainly how function pointers are generated at runtime and how functions are looked up in the function tables (now plural).

Alas, my employer is under no pressure to fund this work, but if you want to take it on, I have some ideas about how to make it work.

embind should continue to work in the old compiler.

Cheers,
Chad

--
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/groups/opt_out.

--

Chad Austin

Technical Director, IMVU

http://engineering.imvu.com

http://chadaustin.me

[Alon Zakai]

Right, sorry for forgetting that - added to the wiki page now.

- Alon

[Mark Callow]

On 2014/02/21 10:17, Alon Zakai wrote:

Perhaps the biggest missing thing is linking support. This is not deprecated, but there are some issues with it - it works on C code, but C++ can break it. For that reason we may want to reconsider our linking approach, so there is no point adding that to fastcomp before doing so. Also, linking is less crucial for fastcomp anyhow - linking has been a way to avoid rebuilding big projects, but fastcomp is fast enough to rebuild entire projects anyhow, and full rebuilds will give more optimal results due to the compiler seeing all the code together and putting it all in one asm.js module.

I'm not entirely sure what you mean by linking support so the following may not be relevant.

Build time is not the only reason for not wanting to build entire projects together.

When creating an Emscripten config from an existing MSVS solution that is configured as multiple projects (e.g. a library and several applications) you want to retain the structure. I have such a solution currently using the old compiler. There the library build generates bitcode. As I understand it, the application compiles generate JS for the library and application.

One may want to deliver a library for people to use without providing its source code. The bitcode file would work for this too.

Regards

    -Mark

--

注意：この電子メールには、株式会社エイチアイの機密情報が含まれている場合が有ります。正式なメール受信者では無い場合はメール複製、 再配信または情報の使用を固く禁じております。エラー、手違いでこのメールを受け取られましたら削除を行い配信者にご連絡をお願いいたし ます.

NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies.

[Alon Zakai]

Static linking of bitcode still works. You can certainly deliver a library in bitcode format that people receive and link with their project, or just build multiple libraries in your project as bitcode (.so, .a, .o, etc.) and link those statically then convert to JS, etc.

What does not work is linking done *after* conversion to JS: dynamic linking or dlopen of JS files. (Those work to some degree in the old compiler, but not in fastcomp, until we figure out our plans there.)

- Alon

--