|New "fastcomp" LLVM backend about to be turned on in incoming branch||Alon Zakai||2/20/14 5:17 PM|
The last missing features for fastcompPerhaps 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.
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.
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.
|This message has been hidden because it was flagged for abuse.|
|Re: New "fastcomp" LLVM backend about to be turned on in incoming branch||Alon Zakai||2/20/14 6:17 PM|
Right, sorry for forgetting that - added to the wiki page now.- Alon
|Re: New "fastcomp" LLVM backend about to be turned on in incoming branch||Mark Callow||2/24/14 8:37 PM|
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
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
注意：この電子メールには、株式会社エイチアイの機密情報が含まれている場合が有ります。正式なメール受信者では無い場合はメール複製、 再配信または情報の使用を固く禁じております。エラー、手違いでこのメールを受け取られましたら削除を行い配信者にご連絡をお願いいたし ます.
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.
|Re: New "fastcomp" LLVM backend about to be turned on in incoming branch||Alon Zakai||2/25/14 12:46 PM|
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.- Alon
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.)