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}
This change replaces the bitwise masking of uses by storing the most general truncation for all uses.
Review URL: https://codereview.chromium.org/1464763003
Cr-Commit-Position: refs/heads/master@{#32248}
port 0ef5ad5ab9 (r32219)
original commit message:
This CL also fixed register usages in MacroAssembler::Allocate() broken by 2fc2cb99 (r32144).
BUG=
Review URL: https://codereview.chromium.org/1473763003
Cr-Commit-Position: refs/heads/master@{#32245}
port 1b1db13549 (r32220)
original commit message:
Change the runtime entries and their associated code stubs for object
and array literal creation to take the closure instead of the raw
literals pointer. This is way easier to deal with (and cleaner) in
TurboFan.
BUG=
Review URL: https://codereview.chromium.org/1472273002
Cr-Commit-Position: refs/heads/master@{#32244}
port 0fb2edd15d (r32217)
original commit message:
We still share the code globally, but if we wanted, it would be easy to
make it per isolate now
BUG=
Review URL: https://codereview.chromium.org/1477683002
Cr-Commit-Position: refs/heads/master@{#32242}
port 9846f386f0 (r32205)
original commit message:
The literal index is being pushed onto the stack while evaluating
the non-constant subexpressions, but never used in fullcodegen (and
hence not used in the optimizing compilers).
BUG=
Review URL: https://codereview.chromium.org/1477673002
Cr-Commit-Position: refs/heads/master@{#32241}
port 7c45b00529 (r32203)
original commit message:
This passes the new.target value in a register instead of through a
side-channel via the construct stub. Note that only TurboFan code uses
the register value so far, but unoptimized code will be switched soon.
BUG=
Review URL: https://codereview.chromium.org/1477663002
Cr-Commit-Position: refs/heads/master@{#32240}
Rolling v8/tools/clang to aeba05c6d90e906ba60a328e9a5b68f25627dc29
Rolling v8/tools/swarming_client to df99a00d96fae932bae824dccba13156bf7eddd0
TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org
Review URL: https://codereview.chromium.org/1475893002
Cr-Commit-Position: refs/heads/master@{#32239}
The first bug was that there are two different "initialization positions"
passed into PatternRewriter::DeclareAndInitializeVariables, and we weren't
setting them all properly for this case.
After further code review, it became clear that we weren't even recording
the correct position (the end of the initializer expression).
The combination of those two bugs caused the hole check elimination code
in full-codegen to skip emitting a hole check.
This patch takes care of both of those things. A follow-up will try
to reduce the number of "initializer positions" we track in the
variable declaration code.
R=littledan@chromium.org
BUG=v8:4568
LOG=n
Review URL: https://codereview.chromium.org/1468143004
Cr-Commit-Position: refs/heads/master@{#32237}
For web compat reasons, we support an initializer in the declaration
part of a for-in loop. But we should disallow this for destructured
declarations (just as we do for lexical declarations). In fact, without
disallowing it, we crash.
Also fix up the PreParser to have the same restrictions here as the parser
(the lexical check was missing there), verified by running the message tests
with --min-preparse-length=0.
In fixing the logic I've also cleaned up the code a bit, removing the
only-called-once DeclarationParsingResult::SingleName method.
BUG=v8:811
LOG=n
Review URL: https://codereview.chromium.org/1471973003
Cr-Commit-Position: refs/heads/master@{#32236}
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=v8:4076
LOG=n
Review URL: https://codereview.chromium.org/1460183002
Cr-Commit-Position: refs/heads/master@{#32234}
Don't replace `TruncateFloat64ToInt32(RoundInt64ToFloat64(value))` with
`value`. Generally, `value` may have a range bigger than the one that
could fit into Int32. Replace it with `TruncateInt64ToInt32(value)`
instead, and only if the `value` fits into Float64 without precision
loss.
Add missing mjsunit test for 52bit multiplication/division optimization
that has landed in refs/heads/master@{#31899}.
BUG=
R=titzer@google.com
Review URL: https://codereview.chromium.org/1433353006
Cr-Commit-Position: refs/heads/master@{#32227}
Reason for revert:
Fails on V8 Fuzzer: https://build.chromium.org/p/client.v8/builders/V8%20Fuzzer/builds/6028
Original issue's description:
> Move --harmony-destructuring-bind to shipping
>
> Also fix CheckConflictingVarDeclarations() to properly handle
> legacy const bindings. Without that change enabling the flag
> causes code like:
>
> function f() { const x; var x; }
>
> to throw an early error, rather than wait to throw the error
> until f is invoked.
>
> BUG=v8:811
> LOG=y
> CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
>
> Committed: https://crrev.com/515093630a4a925a66d550561e38293d49633f10
> Cr-Commit-Position: refs/heads/master@{#32222}
TBR=rossberg@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:811
Review URL: https://codereview.chromium.org/1470333002
Cr-Commit-Position: refs/heads/master@{#32226}
Adds code and tests to support CreateClosure bytecode when building
graphs.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1458603012
Cr-Commit-Position: refs/heads/master@{#32224}
Also fix CheckConflictingVarDeclarations() to properly handle
legacy const bindings. Without that change enabling the flag
causes code like:
function f() { const x; var x; }
to throw an early error, rather than wait to throw the error
until f is invoked.
BUG=v8:811
LOG=y
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
Review URL: https://codereview.chromium.org/1451843002
Cr-Commit-Position: refs/heads/master@{#32222}
sufficient physical registers for all the virtual registers.
This should come in handy for frame elision. There, I noticed that even
for very small functions (==very few virtual registers), because we spill
the context/function marker ranges, we lose the frame elision
opportunity.
There is a subsequent change needed to fully help frame elision -
decoupling spilling of context & function marker from prologue.
BUG=
Review URL: https://codereview.chromium.org/1469743002
Cr-Commit-Position: refs/heads/master@{#32221}
