I actually don't see asm.js work there (it fails on invoke_i being called,
likely because of exceptions). However, differences between asm.js and wasm
ctor evalling are possible, the wasm ctor evaller happens after asm2wasm,
which is after we emterpretify, while in asm.js we do it before we
emterpr
Thanks much for the comment, Alon!
We did some more experiments and found that ASM.JS and WASM seem to have
different behaviors:
1. asm.js "managed to remove 1 ctors" with command "emcc -Oz Source.cpp
-std=c++14 -stdlib=libc++ -s EMTERPRETIFY=1 -s EMTERPRETIFY_ASYNC=1
--proxy-to-worker --bind -
using -s EVAL_CTORS=0 in command line
em++ -Oz -s EVAL_CTORS=0 should work
Refer settings.js
On Saturday, August 5, 2017 at 6:49:39 PM UTC+5:30, awt wrote:
>
> Alon, is there a way in which we can turn off the constructor evaluator
> even if we are using Oz or O3?
--
You received this message
Alon, is there a way in which we can turn off the constructor evaluator even if
we are using Oz or O3?
--
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 ems
It looks like the global it complains about is "eb", the emterpreter base
(where the emterpreted code is placed in linear memory). That isn't known
at compile time, so the ctor evaller can't precompute it away. In other
words, this is a limitation of combining the emterpreter, which allocates
some
