Attempting to build Bug 137707 fails with Linux 64 PGO (and only with
Linux 64 PGO) with the following error:
INFO - /builds/worker/workspace/build/src/js/src/irregexp/RegExpEngine.cpp:2326:5: error: assuming signed overflow does not occur when assuming that (X + c) < X is always false [-Werror=strict-overflow]
INFO - for (int i = interval.from(); i <= interval.to(); i++) {
INFO - ^^^
I suspect that this is actually a bug in PGO itself, rather than in
the code. However, replacing `<= interval.to()` with `!= interval.to()
+ 1` seems to do the trick.
MozReview-Commit-ID: IsayKhgkwWq
--HG--
extra : rebase_source : 6c2fa14a5fe49c1cc5d42afc9f7d57be568f662b
Some tests need to find out js/src to locate their test
data. Exporting this information as part of the environment.
MozReview-Commit-ID: JAefL2arhJL
--HG--
extra : rebase_source : 2c9e9fa39e41844518ed466a88023cc2b94dec55
This patch implements a Binary AST parser matching the latest
binjs-ref parser at this date. The subset of JS recognized matches
ES5, with an AST based on a slightly customized Babylon AST.
At this stage, the parser trusts its input, insofar as it does not
check directives or bindings. Followup patch will introduce checking
of these directives/bindings.
MozReview-Commit-ID: 1nt230rt02R
--HG--
extra : rebase_source : fcefcb0721813910b7a13f7244d85f4ab12502b3
This patch ports to SpiderMonkey the tokenizer currently implemented
in the external binjs-ref tool.
While this tokenizer will clearly not be the tokenizer eventually
shipped to end-users (whether in Firefox or in binjs-ref), the plan is
to keep it both in binjs-ref and in SpiderMonkey (Nightly only) as a
tool for helping test the higher layers of Binjs.
MozReview-Commit-ID: 1i6XnVIf8p5
--HG--
extra : rebase_source : da8f424de70f84bd0403103303f25aa1c424b703
The current "./mach geckodriver" commands runs the geckodriver
binary, but this patch introduces a geckodriver namespace to mach
and renames that command to "./mach geckodriver run".
It also introduces two new commands to build geckodriver and run
its Rust unit tests through "./mach geckodriver build" and "./mach
geckodriver test", respectively.
MozReview-Commit-ID: 5iO9FVkbch2
--HG--
extra : rebase_source : 6395a65526d48e4af5f63f3b23dd3a52801e03a3
This has the virtue of not executing python three times during configure
just to read the same value of milestone.txt and munge it. We can also
remove milestone.py as a happy side effect, so all the milestone
computations can be done in init.configure.
We only had this "for flexibility with other platforms", but given that
we set it to the same thing for all platforms, and nobody has tried to
change that, this flexibility isn't actually needed.
Now that the extra padding is removed, we can end up with data
immediately after indirect jumps. For perf reasons, it is recommended to
insert a UD2 instruction in this case to prevent CPU decoding garbage.
This also works around a Valgrind bug where the tool segfaults in a
similar scenario.
MozReview-Commit-ID: ESk41VgKjOW
In order to try and mitigate crashes on 64-bit FF 57+ on AMD Bobcat
CPUs, insert NOPs before the JIT code buffers. On earlier versions of
these processors, hardware bugs cause crashes to occur in locations
before the JIT code stub. For simplicity, the JitCode* pointer is
shifted even on machines that are unaffected. With the previous patch
fixing over allocation, we end up being size-neutral.
MozReview-Commit-ID: 4LqBfOzv6Qy
When computing worst-case alignment padding, we don't take into account
the buffer already being partially aligned. This saves one word per
JitCode buffer allocation.
MozReview-Commit-ID: ZMwBzp97xy
In the case of InstIsGuard(), the BufferInstructionIterator implementation
forgot that the underlying AssemblerBufferInstIterator is based on
BufferOffsets, the incrementation of which skips pools already.
--HG--
extra : histedit_source : c0520c1e7d4ab4a65d4546ee196192f2164c32a3
This turns the ATOMIC_PTR macro into a function and merges the
prepareMemoryAccess() call into that function, for a nice net cleanup
+ movement of platform code.
(This would be even prettier with C++14 automatic return type
deduction but that is a "not yet" feature.)
MozReview-Commit-ID: JwWOQIli5sS
--HG--
extra : rebase_source : 2bb52ba983455c7a1cef0fa47303e73b1f2704a9
With one exception this removes all platform ifdefs from the high
level of the atomics code generators by moving the register targeting
into RAII wrappers. These wrappers are placed in the new section of
the file, introduced by the previous patch. These wrappers also get
rid of several of the needWhateverTemp() functions because they are
rolled into the RAII wrappers.
The exception is 64-bit atomic ops on x86: here, we are always starved
for registers and must use slightly different APIs, but most of the
code is common and there's a clear pattern at work, so I don't think
this is bad.
Each wrapper carries a method implementing the operation that the
wrapper is for, and calls lower-level code to implement the operation
with appropriate arguments. Thus details of the wrapper are hidden,
and there's minimal risk of abuse or accident.
MozReview-Commit-ID: HeqgqrImxms
--HG--
extra : rebase_source : 73c743bca17dc365e816c64cc2c609dcc3912e09
This creates a new section in the file that sits between the low-level
code generators (above) and the high-level logic and value stack
manipulation (below). The intent is that this section will contain
platform-specific helpers for register targeting when we pop the value
stack.
As explained in a new comment in the code, there are two types of
helpers: simple popXForY methods, of which we've had many; and RAII
wrappers. I've moved the existing popXForY methods into this
section in this patch; the next patch introduces a number of RAII
wrappers.
MozReview-Commit-ID: Fq6TqgsFOkL
--HG--
extra : rebase_source : bd35fe8a835196bb115153042dc73074e788acfc
Given the standard wasm limits for parameters and locals, and assuming
a reasonable limit for the max evaluation stack height, we see that we
need a static frame size around 512KiB in the worst case.
The old limit, 256KiB, was arbitrary (it was just a large number meant
to reduce the attack surface) and we can therefore increase it to
512KiB.
MozReview-Commit-ID: JcKEdEp20Ok
--HG--
extra : rebase_source : 32f78f25f9d9ea369489b7d9a260d29fa8d49859
