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}
port 5166987369 (r32234)
original commit message:
Some highlights of this CL:
* Refactor the mutable state out of Frame into FrameAccessState,
which is maintained and updated during code generation to
record whether sp- or fp-based frame access is currently active
and how deep the stack on top of the frame is.
* The operand resultion in linkage.cc now uses FrameAccessState
to determine how to generate frame-accessing operands.
* Update all platforms to accurately track additionally pushed
stack slots (e.g. arguments for calls) in the FrameAccessState.
* Add a flag, --turbo_sp_frame_access, which forces all frame
access to be sp-based whenever possible. This will likely never
be used in production, but for testing it's useful in verifying
that the stack-tracking of each platform maintained in the
FrameAccessState is correct.
* Use sp-based frame access for gap resolving before tail
calls. This will allow for slightly more efficient restoration
of the frame pointer in the tail call in a later CL.
* Remove most ad hoc groping into CallDescriptors to
determine if a frame is needed, instead consistently use
predicates like needs_frame(), IsCFunctionCall() and
IsJSFunctionCall().
BUG=
Review URL: https://codereview.chromium.org/1479483002
Cr-Commit-Position: refs/heads/master@{#32253}
