In this new version of test262, a number of known failing tests have
been changed to match the ES2016 semantics, which V8 implements.
R=adamk
Review URL: https://codereview.chromium.org/1475793004
Cr-Commit-Position: refs/heads/master@{#32303}
validating that the hot path does not spill - somewhat simpler code.
Cleared the scenario where a range is defined in a deferred block. The
code before was slightly more complicated by not leveraging the
property that these sort of ranges would be completely contained within
deferred blocks.
Moved "spills in deferred blocks" marking to a more appropriate
location.
One thing this CL achieves is correct support for scenarios where a
range is spilled both on the deferred and then hot path, and the ranges
concatenate. I owe better unit testing, which I will add in a subsequent
CL.
BUG=
Review URL: https://codereview.chromium.org/1472803004
Cr-Commit-Position: refs/heads/master@{#32302}
The Float32RoundTruncate operator rounds float32 numbers towards zero.
The operator is currently implemented on x64, ia32, arm, and arm64.
Additionally I added support for the float32 vrintz, vrintn, and vrinta
instructions to the arm simulator.
R=titzer@chromium.org
Review URL: https://codereview.chromium.org/1468303005
Cr-Commit-Position: refs/heads/master@{#32301}
Merge BinaryOperatorReducer into the MachineOperatorReducer class.
It does not need `Revisit()` calls, because the newly inserted nodes are
visited anyway, and there are no other methods that need AdvancedReducer
there.
BUG=
R=titzer@chromium.org
Review URL: https://codereview.chromium.org/1473073004
Cr-Commit-Position: refs/heads/master@{#32298}
Since the gn builders do not resolve the DEPS after patch, the patch cannot contain
both the DEPS change as well the usage of the newly added DEPS.
If the CL mentioned in the title does not land, this CL is to be remove/reverted as well.
BUG=v8:4560
LOG=N
Review URL: https://codereview.chromium.org/1469303004
Cr-Commit-Position: refs/heads/master@{#32296}
Iterating live objects using mark bits is memory bound and already pretty heavy
on the cache as we always need to look at the mark bits, the objects (payload),
and their maps.
This CL changes the object start computation from a table lookup, which was yet
another memory location, to a CPU-bound computation.
BUG=chromium:524425
LOG=N
Review URL: https://codereview.chromium.org/1478623003
Cr-Commit-Position: refs/heads/master@{#32291}
This adds a new JavaScript level operator for regexp literal creation,
similar to what we already have for array and object literals. This
once gets lowered to a call to the FastCloneRegExpStub always.
R=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/1475973002
Cr-Commit-Position: refs/heads/master@{#32288}
Moving Blink from hidden values to private symbols almost doubled the
rate of API calls, as the private symbols API increases the call-depth
scope while the hidden values one didn't.
I manually checked that this fixes the regression on the long running
gmail benchmark but doesn't add new memory reducer GCs on the infinite
scrolling benchmark
BUG=chromium:561325
R=ulan@chromium.org
LOG=n
Review URL: https://codereview.chromium.org/1472193003
Cr-Commit-Position: refs/heads/master@{#32279}
ES6 section 12.2.8.1 states that flags for regular expression literals
must be checked during parsing and invalid flags are early errors. This
change adapts the Scanner and (Pre)Parser to act according to the spec.
This is also a prerequisite to unify the handling of literal creation
(for Objects, Arrays, Regexps, and at some point Classes).
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/1472323002
Cr-Commit-Position: refs/heads/master@{#32273}
This loads all test suites and status files to catch subtle
syntax errors. It also checks basic status file integrity
and common mistakes.
NOTRY=true
Review URL: https://codereview.chromium.org/1475663002
Cr-Commit-Position: refs/heads/master@{#32271}
This passes the new.target value in a register instead of through a
side-channel via the construct stub. The interpreter entry trampoline
stores this value in a bytecode register so that it can be accessed
directly by the interpreter. The size of the interpreter stack frame
hence grows by one slot.
R=oth@chromium.org
BUG=v8:4544
LOG=n
Review URL: https://codereview.chromium.org/1469313002
Cr-Commit-Position: refs/heads/master@{#32264}
The Float32RoundUp operator rounds float32 numbers towards infinity.
The operator is currently implemented on x64, ia32, arm, and arm64.
R=titzer@chromium.org
Review URL: https://codereview.chromium.org/1474963002
Cr-Commit-Position: refs/heads/master@{#32262}
This is "more correct" than WASM_FUNCTION falling through the switch
over code types and using the marker on the stack which contains a bogus
value.
In the long run, there will be two kinds of WASM-related frames: frames
that cross the JS/WASM border, and internal WASM_FUNCTION frames. This
will necessitate a new StackFrame::Type, since the first kind of frame
must treat its parameters as tagged values and the second definitely
should not.
R=mstarzinger@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1470353002
Cr-Commit-Position: refs/heads/master@{#32256}
This is the initial step towards refactoring the regexp literation
creation code to make it less obscure and more similar to the mechanism
we use to create array and object literals. There's now a new runtime
entry %CreateRegExpLiteral with the same interface as the entries for
array and object literals, except that we still pass the flags as
string.
Instead of embedding the hand written native to clone JSRegExp instances
we now have a FastCloneRegExpStub, which behaves similar to the other
FastCloneShallowArrayStub and FastCloneShallowObjectStub that we already
had.
R=mlippautz@chromium.org, yangguo@chromium.org
Review URL: https://codereview.chromium.org/1475823003
Cr-Commit-Position: refs/heads/master@{#32255}
