This patch cleans up wasm compiler selection and a few related things
with as few semantic changes as possible. The intent is to centralize
compiler availability computation so that all parts of the system stay
in sync and it is easy to change compiler selection policy.
First, we introduce new predicates <Compiler>Available(cx) to test for
the actual availability of a compiler. These predicates take into
account whether a compiler is compiled into the executable, whether it
supports the hardware, whether it is (currently) selected by
options/switches, and whether it can be used as a result of the
runtime environment (for example, Ion and Cranelift are not available
if the debugger is observing the page or if the GC feature is enabled;
Cranelift is not available if shared memory and atomics are enabled).
We switch to using these predicates almost everywhere that used
<Compiler>CanCompile() or cx->options().wasm<Compiler>(), since those
don't tell the full story.
Second, we implement a priority order of the optimizing compilers and
make it easy to change this order (see comments in code). At the
moment, Cranelift is prioritized over Ion since Ion is enabled by
default and Cranelift is not; thus the desire of somebody flipping the
pref for Cranelift is to deselect Ion. The priority order may change
in the future or may become platform-dependent. The default compiler
selection in both browser and shell remains Baseline+Ion.
Third, we rename HasCompilerSupport() as HasPlatformSupport(), since
the predicate does not test whether compilers are available, only
whether they are present in the executable and support the hardware.
And to make that more sensible, <Compiler>CanCompile() is renamed
as <Compiler>PlatformSupport().
Fourth, we remove some redundant testing predicates (we don't need
both wasmDebugSupport and wasmDebuggingIsSupported, nor do we need
wasmUsesCranelift because wasmCompileMode is more reliable).
Fifth, we introduce a few new test cases that try to ensure that
compiler selection works as it should. These are white-box and may
need to change if the compiler priority order changes.
Sixth, we rename the internal wasm::Has<Feature>Support() predicates
as wasm::<Feature>Available(), since they all actually test for
compiler availability.
Differential Revision: https://phabricator.services.mozilla.com/D64946
--HG--
extra : moz-landing-system : lando
Update some of the bulk memory test cases so that they do not run
tests on shared memory if shared memory is disabled in the engine.
Differential Revision: https://phabricator.services.mozilla.com/D66191
--HG--
extra : moz-landing-system : lando
This passes jit-test and jstest locally. I still see some references
in jsapi-tests/binast, but I haven't looked into running those yet.
The asm.js warning stuff is a bit confusing. It seems like there are multiple mistakes?
asmLink claims that it should issue a warning. But it sets "werror", so this would always
throw an exception if linking actually threw an exception.
Some tests using assertAsmDirectiveFail aren't even valid JS programs ..
Differential Revision: https://phabricator.services.mozilla.com/D66225
--HG--
extra : moz-landing-system : lando
Add annotations to vertex shaders so that SWGL can detect when a vertex attribute
is generated by per-instance data rather than per-vertex data.
Differential Revision: https://phabricator.services.mozilla.com/D65614
--HG--
extra : moz-landing-system : lando
Add annotations to vertex shaders so that SWGL can detect when a vertex attribute
is generated by per-instance data rather than per-vertex data.
Differential Revision: https://phabricator.services.mozilla.com/D65614
--HG--
extra : moz-landing-system : lando
Use the same mechanism for for-in and destructuring loops. Add loop phis to
the iterators_ Vector and at the end of IonBuilder mark these phis and phis
depending on them as having implicit uses.
Differential Revision: https://phabricator.services.mozilla.com/D66005
--HG--
extra : moz-landing-system : lando
This function is only interested in the (network of) phis that use iterators
and we can ignore other uses.
Depends on D66003
Differential Revision: https://phabricator.services.mozilla.com/D66004
--HG--
extra : moz-landing-system : lando
Rename to TryNoteIterAllNoGC and refactor things a bit so that we don't need
a JSContext* and RootedScript. WarpBuilder will likely want to use this iterator
off-thread.
Differential Revision: https://phabricator.services.mozilla.com/D66003
--HG--
extra : moz-landing-system : lando
This was disabled in bug 1599197 but this build is not really like the other
Linux32 builds: it runs ARM32 JIT code in SpiderMonkey's ARM32 simulator.
Differential Revision: https://phabricator.services.mozilla.com/D66228
--HG--
extra : moz-landing-system : lando
This is a tentative fix, but I think android viewport shenanigans are the only
reason this could be flaky only on Android.
Differential Revision: https://phabricator.services.mozilla.com/D66374
--HG--
extra : moz-landing-system : lando