Noissue - [emscripten] Added -fno-exception flag, reduces build size by 20%

This is mostly FYI, the change is quite uncontroversial - we removed all exception processing a while ago. libcxx is still using exceptions however, so this change has significant impact - 20% reduction in build size. I compared the builds and the difference comes mostly from libcxx dragging in lots of dependecies in order to handle exceptions, including stream I/O and even pthreads. Plus, quite a few globals went away and do not need to be initialized any more. Also, a few functions could be optimized a bit better now that calls cannot throw. But we have to be careful using std::vector of course, no length checking will be performed now (not that an exception thrown would have saved us before).

[Wladimir Palant, 2017-04-16 14:06:23]

I checked and not having exceptions in libcxx doesn't mean that std::vector will
ignore length errors - it will rather call ___assert_fail() which in turn will
throw a JavaScript exception. So we will crash which is desirable in this
scenario.

[sergei, 2017-04-18 08:02:10]

LGTM only because it very positively influences the size of the result and it
does not hurt right now (or we are not aware about it :) ).

Basically, I think we are not using API of C++, merely of C, so, if the size is
so important, maybe it could be reduced even more by not linking with libc++ and
linking only with libc. It will require to implement few functions, like
`operator new/delete` (and for arrays), some handlers (like atexit, destroying
global variables, which is likely not relevant for us) and maybe a couple of
more functions. It's pretty popular technique among developers for
microcontrollers, from where we could borrow the implementation of functions of
libc++.

[Wladimir Palant, 2017-04-18 08:53:07]

On 2017/04/18 08:02:10, sergei wrote:
> LGTM only because it very positively influences the size of the result and it
> does not hurt right now (or we are not aware about it :) ).

Well, we explicitly made sure not to use exceptions, these are known to be slow
with Emscripten. We are also careful not to trigger any exceptions in STL. So we
are only being consequent.

> Basically, I think we are not using API of C++, merely of C, so, if the size
is
> so important, maybe it could be reduced even more by not linking with libc++
and
> linking only with libc. It will require to implement few functions, like
> `operator new/delete` (and for arrays), some handlers (like atexit, destroying
> global variables, which is likely not relevant for us) and maybe a couple of
> more functions. It's pretty popular technique among developers for
> microcontrollers, from where we could borrow the implementation of functions
of
> libc++.

This might actually be worth doing. As I've noticed, we are currently pulling in
libcxxabi as a dependency for no good reason - this is mostly due to new/delete
operators which would be easy to replace by our own trivial implementations.
I've already verified (by messing with Emscripten code) that removing that
dependency would reduce the size by another 5 kB - that's around 3%. If doing it
without changing Emscripten isn't too complicated, it might be worth it - but we
would have to get rid of all libcxx dependencies then, meaning std::vector as
well.