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
An explanation of the Mozilla Source Code Directory Structure and links to
project pages with documentation can be found at:
https://firefox-source-docs.mozilla.org/contributing/directory_structure.html
For information on how to build Mozilla from the source code and create the patch see:
https://firefox-source-docs.mozilla.org/contributing/how_to_contribute_firefox.html
If you have a question about developing Mozilla, and can't find the solution
on https://developer.mozilla.org, you can try asking your question on Matrix at chat.mozilla.org in `Introduction` (https://chat.mozilla.org/#/room/#introduction:mozilla.org) channel.
Nightly development builds can be downloaded from:
https://archive.mozilla.org/pub/firefox/nightly/latest-mozilla-central/
- or -
https://www.mozilla.org/firefox/channel/desktop/#nightly
Keep in mind that nightly builds, which are used by Mozilla developers for
testing, may be buggy.
23854fd5a5