All the supported compilers support a GNU AS-like syntax, with only a
few details varying. It means we can use a single, simpler, way to
include the ICU data file, instead of 3 different ways, including one
that uses armasm64.exe, possibly wrapped with Wine.
Differential Revision: https://phabricator.services.mozilla.com/D82144
This commit enable reference-types by default. The existing config/ifdef'ery is
spared to allow for an easier backout and to support Cranelift until it gains
support for the feature.
Depends on D81012
Differential Revision: https://phabricator.services.mozilla.com/D81013
This commit enables the bulk-memory-operations feature by default. The config/
ifdef'ery is spared to allow for easier backouts if needed.
Differential Revision: https://phabricator.services.mozilla.com/D81012
This patch generalizes the x64 code that was moved into x86-shared
code in the previous patch, and makes it all work for x86.
Generally the changes are pedestrian. The most interesting bit is
that signed right shift i64x2 is now scalarized in the compilers, not
in the macroassemblers, as this simplifies code everywhere. This
gives rise to a new kind of porting API that reveals information about
what the macroassembler supports on the platform, in the form of the
MustScalarize/MustMaskShiftCount predicates in MacroAssembler.h.
Multiply i64x2, which is scalarized in the macroassemblers now, could
have been subjected to the same treatment, but I did not do so (yet)
because this op presented fewer problems than the right shift. (Discuss.)
Differential Revision: https://phabricator.services.mozilla.com/D74935
I kept a running list of code that would be dead once we removed the old engine. This is what was on that list.
Note: The regexp_parse tests used a testing function that parsed a regexp and returned an AST to compare against the expected AST. They are being deleted because the tests are fragile in the face of upstream changes, not particularly useful, and a lot of work to convert.
Depends on D77727
Differential Revision: https://phabricator.services.mozilla.com/D77728
Currently our wasm-gc prototypes requires that typed objects are enabled,
and of course it is also dependent on reference types. So make sure the
default is computed correctly and die during configure if wasm-gc is
requested while the other options are disabled.
Differential Revision: https://phabricator.services.mozilla.com/D77780
At the same time, because it's now simpler to do so, set the right data
file name for big-endians, even though we don't have or produce it
(bug #1264836). Also remove USE_ICU, which is redundant with
JS_HAS_INTL_API, and actively break the build at configure time when
using --without-intl-api with Firefox because this hasn't actually
worked for close to 3 years (since bug 1402048).
Differential Revision: https://phabricator.services.mozilla.com/D77416
Versions of NSPR >= 4.10 come with a pkg-config file. We currently
depend on 4.9.2 for spidermonkey, but much more recent versions for
Firefox. 4.10 is less than a year newer than 4.9.2, and 4.10 is 7 years
old, so bumping the requirement to 4.10 is not really a big deal.
With the use of pkg-config, --with-nspr-cflags and --with-nspr-libs are
not needed.
None of the AC_TRY_COMPILE tests were any useful because
PR_STATIC_ASSERT and PR_UINT64 have been when we look for them since
4.8.6 and 4.9 respectively.
Differential Revision: https://phabricator.services.mozilla.com/D77412
Change --wasm-simd to --no-wasm-simd and flip the default for both this
switch and for the about:config flag.
Add testing directives so that we test baseline, ion, and --no-wasm-simd.
Differential Revision: https://phabricator.services.mozilla.com/D71819
This patch removes the compile-time and run-time flags that disable BigInt/I64 so that the feature can be shipped. It also adjusts/removes tests as appropriate to account for the removed code paths.
Differential Revision: https://phabricator.services.mozilla.com/D74142
The tracing framework is unused but Matthew found the hook points useful, so this changes those into empty inline functions that can be used to insert probes.
Differential Revision: https://phabricator.services.mozilla.com/D73816
We add a configuration option for SIMD and apply ENABLE_WASM_SIMD
throughout the engine as appropriate, mostly to insert #error or
MOZ_CRASH where things need to be done in later patches or for
architectures that we won't currently consider.
We add a command line switch for the shell and an option for
about:config and plumb the value of this through the engine.
Differential Revision: https://phabricator.services.mozilla.com/D57940
For many years now this has covered all our JIT codegen, not just Ion, so this is
a lot less confusing. Using --enable-ion/--disable-ion now results in an error that
suggests the new name.
Differential Revision: https://phabricator.services.mozilla.com/D69579
--HG--
extra : moz-landing-system : lando
These days we can get the same information by checking JS_CODEGEN_NONE, so let's
do that.
Differential Revision: https://phabricator.services.mozilla.com/D69578
--HG--
extra : moz-landing-system : lando
Now that multi-value is code-complete, we enable it on nightly browsers
in addition to shell builds.
Differential Revision: https://phabricator.services.mozilla.com/D68791
--HG--
extra : moz-landing-system : lando
Now that multi-value is code-complete, we enable it on nightly browsers
in addition to shell builds.
Differential Revision: https://phabricator.services.mozilla.com/D68791
--HG--
extra : source : 98f78bb873005cd22f5794dc53b5cfb41f94c83b
Now that multi-value is code-complete, we enable it on nightly browsers
in addition to shell builds.
Differential Revision: https://phabricator.services.mozilla.com/D68791
--HG--
extra : moz-landing-system : lando
The previous fix here was a hack that would disable SAB in the JS
shell on non-nightly, but this breaks various tests that no longer
guard properly for SAB. Instead of embedding the hack more deeply by
changing those tests, we fix it the way it should have been from the
outset: SAB is enabled in the shell on all channels but can be
disabled by a switch.
Differential Revision: https://phabricator.services.mozilla.com/D68515
--HG--
extra : moz-landing-system : lando
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
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
Ryan Hunt
Mike Hommey
Kannan Vijayan
Ted Campbell
Csoregi Natalia
Razvan Maries
Lars T Hansen
Iain Ireland
Bogdan Tara
Asumu Takikawa
Sebastian Hengst
Narcis Beleuzu
Andy Wingo
Jon Coppeard
Jan de Mooij
Dorel Luca
Daniel Varga
shindli
Tooru Fujisawa