This adds a new ignition_turbofan testing variant that'll
allow switching turbofan off in the other ignition variant.
The switch will happen in a follow up after reconfiguring
the bots.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1922623003
Cr-Commit-Position: refs/heads/master@{#35790}
This avoids regenerating baseline code for a closure when such code
already exists for the shared function info. This is also important
because the baseline code might contain deoptimization support.
R=rmcilroy@chromium.org
BUG=chromium:606376
LOG=n
Review URL: https://codereview.chromium.org/1916833002
Cr-Commit-Position: refs/heads/master@{#35785}
This is the first step to implement parallel compilation. The next steps
will be to split the pipeline to separate instruction selection from
code generation, and then to call all that from within a CancelableTask.
R=titzer@chromium.org
Review URL: https://codereview.chromium.org/1900713005
Cr-Commit-Position: refs/heads/master@{#35784}
Rolling v8/build/gyp to 4cf07e8d616739f6484e46c9359b2a35196b2585
Rolling v8/buildtools to 2a9a29fbdc2170c25e5cc0f642213eb7b3e7bc98
TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org
Review URL: https://codereview.chromium.org/1917073004
Cr-Commit-Position: refs/heads/master@{#35783}
port c005029aa4 (r35754)
original commit message:
Use the FastNewSloppyArgumentsStub in the interpreter when function doesn't have
duplicate parameters.
BUG=
Review URL: https://codereview.chromium.org/1922803002
Cr-Commit-Position: refs/heads/master@{#35781}
The first version of --harmony-for-in avoided throwing PreParser
errors in order to retain use counting. This patch threads
use_counts_ through to the PreParser to allow use counting in
the PreParser while also throwing errors for this case.
Also slightly refactored the Parser code to do a little less
code duplication.
BUG=v8:4942
LOG=y
Review URL: https://codereview.chromium.org/1913203002
Cr-Commit-Position: refs/heads/master@{#35780}
This patch also fixed three misaligned semaphores.
This reverts commit 80c73e2cde.
BUG=chromium:605349
LOG=NO
Review URL: https://codereview.chromium.org/1917923002
Cr-Commit-Position: refs/heads/master@{#35773}
Port 0231a7efa2
Original commit message:
This allows us to get rid of the "push TruncateFloat64ToInt32 into Phi"
trick that was used in the MachineOperatorReducer to combine the
ChangeTaggedToFloat64 and TruncateFloat64ToInt32 operations. Instead of
doing that later, we can just introduce the proper operator during the
representation selection directly.
Also separate the TruncateFloat64ToInt32 machine operator, which had two
different meanings depending on a flag (either JavaScript truncation or
C++ style round to zero). Now there's a TruncateFloat64ToWord32 which
represents the JavaScript truncation (implemented via TruncateDoubleToI
macro + code stub) and the RoundFloat64ToInt32, which implements the C++
round towards zero operation (in the same style as the other WebAssembly
driven Round* machine operators).
R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, mbrandy@us.ibm.com
BUG=
LOG=N
Review URL: https://codereview.chromium.org/1921733003
Cr-Commit-Position: refs/heads/master@{#35771}
If the target is deprecated, the object will be updated on first store. If the source for that store equals the target, this will invalidate the cached representation of the source. Preventively upgrade the target.
BUG=chromium:604300
LOG=n
Review URL: https://codereview.chromium.org/1905933002
Cr-Commit-Position: refs/heads/master@{#35770}
These also lower to subgraphs that have to be connected to the effect
and control chains, otherwise removing the atomic regions around heap
allocations would still be unsound.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1916763003
Cr-Commit-Position: refs/heads/master@{#35762}
This will allow to pull in gyp as a deps to the same location
as chromium (tools/gyp not build/gyp), needed for gn switch.
This is the first step of a 3-way move.
1) Copy v8.gyp in v8
2) Update references in embedders (follow up)
3) Remove old v8.gyp (follow up)
BUG=chromium:474921
LOG=n
NOTRY=true
Review URL: https://codereview.chromium.org/1920793002
Cr-Commit-Position: refs/heads/master@{#35760}
This adds a baseline tier to the compilation pipeline. Currently this
tier is used to model a path from the interpreter to optimized code via
full-codegen code (to ensure sufficient type feedback). Switching from
the unoptimized tier to the baseline tier is limited to happen only when
there are no activations of the given function on the stack.
R=rmcilroy@chromium.org,bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1903273004
Cr-Commit-Position: refs/heads/master@{#35757}
Use the FastNewSloppyArgumentsStub in the interpreter when function doesn't have
duplicate parameters.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1909903003
Cr-Commit-Position: refs/heads/master@{#35754}
The Oddball::to_number_raw field contains the actual double value of the
Oddball converted to a number, and is located at the same offset as the
HeapNumber::value field, so for lowering changes we don't need to check
for undefined (or any other oddball explicitly).
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1922443002
Cr-Commit-Position: refs/heads/master@{#35753}
This patch make sure that the nop instructions used to mark floating-point
arguments live range begin will not be moved by the scheduler.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1896933004
Cr-Commit-Position: refs/heads/master@{#35751}
The ObjectIs<Type> predicates compile down to diamonds (in the general
case), and those should be connected properly to the control and effect
chain in the linearization pass.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1912743002
Cr-Commit-Position: refs/heads/master@{#35748}
port 0231a7efa2 (r35743)
original commit message:
This allows us to get rid of the "push TruncateFloat64ToInt32 into Phi"
trick that was used in the MachineOperatorReducer to combine the
ChangeTaggedToFloat64 and TruncateFloat64ToInt32 operations. Instead of
doing that later, we can just introduce the proper operator during the
representation selection directly.
Also separate the TruncateFloat64ToInt32 machine operator, which had two
different meanings depending on a flag (either JavaScript truncation or
C++ style round to zero). Now there's a TruncateFloat64ToWord32 which
represents the JavaScript truncation (implemented via TruncateDoubleToI
macro + code stub) and the RoundFloat64ToInt32, which implements the C++
round towards zero operation (in the same style as the other WebAssembly
driven Round* machine operators).
BUG=
Review URL: https://codereview.chromium.org/1912403002
Cr-Commit-Position: refs/heads/master@{#35745}
port 5c8609de9d (r35724)
original commit message:
This ensures the InterpreterEntryTrampoline heals code entry fields
inside closures when being called without a valid bytecode array. This
is preparatory work to allow removal of bytecode when switching some
functions to other types of code.
BUG=
Review URL: https://codereview.chromium.org/1920713002
Cr-Commit-Position: refs/heads/master@{#35744}
This allows us to get rid of the "push TruncateFloat64ToInt32 into Phi"
trick that was used in the MachineOperatorReducer to combine the
ChangeTaggedToFloat64 and TruncateFloat64ToInt32 operations. Instead of
doing that later, we can just introduce the proper operator during the
representation selection directly.
Also separate the TruncateFloat64ToInt32 machine operator, which had two
different meanings depending on a flag (either JavaScript truncation or
C++ style round to zero). Now there's a TruncateFloat64ToWord32 which
represents the JavaScript truncation (implemented via TruncateDoubleToI
macro + code stub) and the RoundFloat64ToInt32, which implements the C++
round towards zero operation (in the same style as the other WebAssembly
driven Round* machine operators).
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1919513002
Cr-Commit-Position: refs/heads/master@{#35743}
If a deferred block has multiple predecessors, they have to be
all deferred. Otherwise, we can run into a situation where if a range
that spills only in deferred blocks inserts its spill in the block, and
other ranges need moves inserted by ResolveControlFlow in the predecessors,
the register of the range spilled in the deferred block may be clobbered.
To avoid that, when a deferred block has multiple predecessors, and some
are not deferred, we add a non-deferred block to collect all such edges.
This CL addresses the validator assertion failure the referenced issue, as well
as the greedy allocator failure - which was caused by the situation described
above.
BUG=v8:4940
LOG=n
Review URL: https://codereview.chromium.org/1912093005
Cr-Commit-Position: refs/heads/master@{#35742}
Need to use the kHashFieldSlot rather than kHashFieldOffset for
pointer-sized memory accesses.
(Fix for "[builtins] Migrate String.prototype.charCodeAt and String.prototype.charAt to TurboFan.")
R=bmeurer@chromium.org, epertoso@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1907393002
Cr-Commit-Position: refs/heads/master@{#35741}
