This moves processing of jumps out of bytecode array builder and into
bytecode array writer. This simplifies the pipeline by avoiding having
to flush for offset and patch up offsets in bytecode array builder based
on what was emitted by the bytecode array writer.
This also enables future refactorings to add dead code elimination back
into the pipeline, and move processing of scalable operand sizes to the
end of the pipeline (in the bytecode array writer) rather than having to
deal with scalable operand types throughout pipeline.
BUG=v8:4280,chromium:616064
Review-Url: https://codereview.chromium.org/2035813002
Cr-Commit-Position: refs/heads/master@{#36716}
This change introduces five fused bytecodes for common bytecode
sequences on popular websites. These are LdrNamedProperty,
LdrKeyedProperty, LdrGlobal, LdrContextSlot, and LdrUndefined. These
load values into a destination register operand instead of the
accumulator. They are emitted by the peephole optimizer.
BUG=v8:4280
LOG=N
Review-Url: https://codereview.chromium.org/1985753002
Cr-Commit-Position: refs/heads/master@{#36507}
Makes LogicalNot bytecode not do the ToBoolean operation, and add support in the
peephole optimizer to choose between the appropriate bytecode depending upon
whether the previous bytecode emitted a boolean or not.
BUG=v8:4280
LOG=N
Review-Url: https://codereview.chromium.org/1985033002
Cr-Commit-Position: refs/heads/master@{#36295}
This change introduces a pipeline for the final stages of
bytecode generation.
The peephole optimizer is made distinct from the BytecodeArrayBuilder.
A new BytecodeArrayWriter is responsible for writing bytecode. It
also keeps track of the maximum register seen and offers a potentially
smaller frame size.
R=rmcilroy@chromium.org
LOG=N
BUG=v8:4280
Review-Url: https://codereview.chromium.org/1947403002
Cr-Commit-Position: refs/heads/master@{#36220}
DevTools uses the debug interrupt to trap on function entry. Without
source position at the stack check, we would get bogus source positions.
R=mstarzinger@chromium.org
BUG=chromium:595646
LOG=N
Review-Url: https://codereview.chromium.org/1925063002
Cr-Commit-Position: refs/heads/master@{#35864}
The new bytecodes replace two runtime functions. They are still unsupported by the bytecode graphbuilder, though.
BUG=v8:4907
LOG=n
Review URL: https://codereview.chromium.org/1904933002
Cr-Commit-Position: refs/heads/master@{#35716}
Removes the register file machine register from the interpreter and
replaces it will loads from the parent frame pointer. As part of this
change the raw operand values for register values changes to enable the
interpreter to keep using the operand value as the offset from the
parent frame pointer.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1894063002
Cr-Commit-Position: refs/heads/master@{#35618}
Introduces a bytecode whose handler executes the equivalent of %_IsArray and %_IsJSReceiver without a runtime call.
BUG=v8:4822
LOG=y
Review URL: https://codereview.chromium.org/1645763003
Cr-Commit-Position: refs/heads/master@{#34983}
This change introduces wide prefix bytecodes to support wide (16-bit)
and extra-wide (32-bit) operands. It retires the previous
wide-bytecodes and reduces the number of operand types.
Operands are now either scalable or fixed size. Scalable operands
increase in width when a bytecode is prefixed with wide or extra-wide.
The bytecode handler table is extended to 256*3 entries. The
first 256 entries are used for bytecodes with 8-bit operands,
the second 256 entries are used for bytecodes with operands that
scale to 16-bits, and the third group of 256 entries are used for
bytecodes with operands that scale to 32-bits.
LOG=N
BUG=v8:4747,v8:4280
Review URL: https://codereview.chromium.org/1783483002
Cr-Commit-Position: refs/heads/master@{#34955}
TestNotEqualsStrict is converted to a TestEqualsStrict and logical not
by the parser. Also, CompareIC does not have an implementation for
TestNotEqualsStrict. Hence, removing this bytecode.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1768593002
Cr-Commit-Position: refs/heads/master@{#34527}
Similar to fullcodegen, Ignition now also marks a for-in statement as
slow (via the TypeFeedbackVector) when we have to call %ForInFilter,
i.e. we either have no enumeration cache or the receiver map changes
during an iteration of the for-in map.
R=mstarzinger@chromium.org
BUG=v8:3650
LOG=n
Review URL: https://codereview.chromium.org/1755563002
Cr-Commit-Position: refs/heads/master@{#34391}
Reason for revert:
It is not a good idea to call CallICStub from the builtin. It might be sensitive to the frame structure. Constructing a internal frame might cause problems. It is much better to inline the code related to the type feedback vector into the builtin.
Original issue's description:
> [Interpreter] Implements calls through CallICStub in the interpreter.
>
> Calls are implemented through CallICStub to collect type feedback. Adds
> a new builtin called InterpreterPushArgsAndCallIC that pushes the
> arguments onto stack and calls CallICStub.
>
> Also adds two new bytecodes CallIC and CallICWide to indicate calls have to
> go through CallICStub.
>
> MIPS port contributed by balazs.kilvady.
>
> BUG=v8:4280, v8:4680
> LOG=N
>
> Committed: https://crrev.com/20362a2214c11a0f2ea5141b6a79e09458939cec
> Cr-Commit-Position: refs/heads/master@{#34244}
TBR=rmcilroy@chromium.org,mvstanton@chromium.org,mstarzinger@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4280, v8:4680
Review URL: https://codereview.chromium.org/1731253003
Cr-Commit-Position: refs/heads/master@{#34252}
Calls are implemented through CallICStub to collect type feedback. Adds
a new builtin called InterpreterPushArgsAndCallIC that pushes the
arguments onto stack and calls CallICStub.
Also adds two new bytecodes CallIC and CallICWide to indicate calls have to
go through CallICStub.
MIPS port contributed by balazs.kilvady.
BUG=v8:4280, v8:4680
LOG=N
Review URL: https://codereview.chromium.org/1688283003
Cr-Commit-Position: refs/heads/master@{#34244}
This CL introduces two new bytecodes TailCall and TailCallWide.
BUG=v8:4698,v8:4687
LOG=N
Review URL: https://codereview.chromium.org/1698273003
Cr-Commit-Position: refs/heads/master@{#34083}
Adds JumpIfNotHoleConstant and JumpIfNotHoleConstantWide bytecodes
and removes JumpIfHole bytecode.
In situations with large numbers of constants, the generator would
fail because an 8-bit constant could not be reserved for
JumpIfHole/JumpIfNotHole and so a 16-bit constant would be reserved.
Then when patching the bytecode the patcher would discover there was
no wide constant variant of the emitted jump.
BUG=v8:4280,v8:4680
LOG=N
Review URL: https://codereview.chromium.org/1697473002
Cr-Commit-Position: refs/heads/master@{#33952}
This replaces the bytecode in question with a runtime call within the
bytecode stream. The tradeoff is to safe one bytecode opcode for more
expensive encoding of lookup slot deletion.
R=rmcilroy@chromium.org
Review URL: https://codereview.chromium.org/1690913002
Cr-Commit-Position: refs/heads/master@{#33907}
Add dedicated %LoadLookupSlot, %LoadLookupSlotInsideTypeof,
%LoadLookupSlotForCall, %StoreLookupSlot_Sloppy and
%StoreLookupSlot_Strict runtime entry points and use them
appropriately in the various compilers. This way we can
finally drop the machine operators from the JS graph level
completely in TurboFan.
Also drop the funky JSLoadDynamic operator from TurboFan,
which was by now just a small wrapper around the runtime
call to %LoadLookupSlot.
R=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/1683103002
Cr-Commit-Position: refs/heads/master@{#33880}
This allows us to remove the somewhat awkward BuildLoadObjectField
from the BytecodeGraphBuilder and also allows us to simplify the
bytecode stream for class literals.
R=oth@chromium.org
Review URL: https://codereview.chromium.org/1678103002
Cr-Commit-Position: refs/heads/master@{#33820}
Adds implementation and tests to support const/let variables in the
interpreter.
BUG=v8:4280,v8:4679
LOG=N
Review URL: https://codereview.chromium.org/1634153002
Cr-Commit-Position: refs/heads/master@{#33819}
Replace the somewhat awkward RestParamAccessStub, which would always
call into the runtime anyway with a proper FastNewRestParameterStub,
which is basically based on the code that was already there for strict
arguments object materialization. But for rest parameters we could
optimize even further (leading to 8-10x improvements for functions with
rest parameters), by fixing the internal formal parameter count:
Every SharedFunctionInfo has a formal_parameter_count field, which
specifies the number of formal parameters, and is used to decide whether
we need to create an arguments adaptor frame when calling a function
(i.e. if there's a mismatch between the actual and expected parameters).
Previously the formal_parameter_count included the rest parameter, which
was sort of unfortunate, as that meant that calling a function with only
the non-rest parameters still required an arguments adaptor (plus some
other oddities). Now with this CL we fix, so that we do no longer
include the rest parameter in that count. Thereby checking for rest
parameters is very efficient, as we only need to check whether there is
an arguments adaptor frame, and if not create an empty array, otherwise
check whether the arguments adaptor frame has more parameters than
specified by the formal_parameter_count.
The FastNewRestParameterStub is written in a way that it can be directly
used by Ignition as well, and with some tweaks to the TurboFan backends
and the CodeStubAssembler, we should be able to rewrite it as
TurboFanCodeStub in the near future.
Drive-by-fix: Refactor and unify the CreateArgumentsType which was
different in TurboFan and Ignition; now we have a single enum class
which is used in both TurboFan and Ignition.
R=jarin@chromium.org, rmcilroy@chromium.orgTBR=rossberg@chromium.org
BUG=v8:2159
LOG=n
Review URL: https://codereview.chromium.org/1676883002
Cr-Commit-Position: refs/heads/master@{#33809}
Moves the stack check from the function entry trampoline to instead be
after function activation using an explicit StackCheck bytecode. Also
add stack checks on back edges of loops.
BUG=v8:4280,v8:4678
LOG=N
Review URL: https://codereview.chromium.org/1665853002
Cr-Commit-Position: refs/heads/master@{#33730}
Moves the temporary register allocator out of the bytecode array
builder into TemporaryRegisterAllocator class and adds unittests.
Particular must be taken around the translation window boundary
motivating the addition of tests.
Also adds a Clear() method to IdentityMap() which is called by
the destructor. This allows classes to hold an IdentityMap if
they are zone allocated. Classes must call Clear() before the zone
is re-cycled or face v8 heap corruption.
BUG=v8:4280,v8:4675
LOG=N
Review URL: https://codereview.chromium.org/1651133002
Cr-Commit-Position: refs/heads/master@{#33686}
This increases the size of register operands to be 16-bit.
Not all bytecodes have wide register variants, so when they are
needed a register translator will copy them into a small area
reserved at the top of the 8-bit register range and these registers
are supplied as arguments to the bytecode with 8-bit operands.
This is non-intrusive for typical bytecode where the number of
registers is less than 120. For bytecodes with wide register
operands (above the window) their index needs to be translated
to avoid the reserved translation window.
Enables splay.js to run in Octane and a handful of mjsunit tests.
BUG=v8:4280,v8:4675
LOG=NO
Review URL: https://codereview.chromium.org/1613163002
Cr-Commit-Position: refs/heads/master@{#33516}
This adds an explicit ReThrow bytecode to be used in the modelling of
try-finally statements. An exception that is being re-thrown should not
trigger message object creation or location computation and hence cannot
use the existing Throw bytecode.
R=rmcilroy@chromium.org
TEST=cctest/test-interpreter/InterpreterTryFinally
BUG=v8:4674
LOG=n
Review URL: https://codereview.chromium.org/1621673002
Cr-Commit-Position: refs/heads/master@{#33472}
o Adds wide variants of bytecodes that have operands describing ranges
of registers. The upcoming wide register support does not suppport
re-mapping ranges.
o Adds kRegPair16 and kRegTriple16 operands required for new wide
bytecodes and renames Count8/Count16 operands to RegCount8/RegCount16.
o Removes Exchange bytecodes
BUG=v8:4675
LOG=NO
Review URL: https://codereview.chromium.org/1595103006
Cr-Commit-Position: refs/heads/master@{#33389}
Make ForInPrepare take a kRegTriple8 operand and ForInNext take kRegPair8
operand for cache state. This is to ensure that the cache state output of
ForInPrepare is in consecutive registers to allow us to deopt the
ForInPrepare node from TF->Ignition (to be done in a followup CL).
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1584813002
Cr-Commit-Position: refs/heads/master@{#33357}
Split RegisterAllocationScope out of ExpressionResult and allocate one
for each statement. This ensures that we always have an outer register
allocation scope for statement code (used in CountOperation and
RegisterExecutionResult). Also refactored the register allocator code to
move it to it's own file and rename from TemporaryRegisterScope to
BytecodeRegisterAllocator.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1587033002
Cr-Commit-Position: refs/heads/master@{#33296}
Adds support for calling runtime functions which return a pair of
values. Adds the bytecode CallRuntimePair. Also adds support to TurboFan
for calling stubs which return multiple values.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1568493002
Cr-Commit-Position: refs/heads/master@{#33181}
This increases the size of addressable constant pool entries for jumps
to match other bytecodes using operands indexing the constant pool.
This change also introduces reservations for constant pool entries.
Reservations are used for forward jumps to ensure a constant pool entry
will be available when the jump target (label) is bound and the jump is
patched up in the bytecode array.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1546683002
Cr-Commit-Position: refs/heads/master@{#33125}
New bytecodes for making registers with indicies wider than 1-byte
accessible.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1555713002
Cr-Commit-Position: refs/heads/master@{#33091}
Changes LoadGlobal, StoreGlobal, LoadNamedProperty, and StoreNamedProperty to accept
the name of variable instead of index into the constant pool entry. Also made
GetConstantPoolEntry as a private function since it is no longer used outside of
BytecodeArrayBuilder.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1546643002
Cr-Commit-Position: refs/heads/master@{#33020}
Adds support for deleting a variable in a lookup slot. Adds a new bytecode,
its implementation and tests. Also adds support for this bytecode to the
bytecode graph builder.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1542083002
Cr-Commit-Position: refs/heads/master@{#33019}
A pre-requisite for this change was changing the interpreter to use
Runtime::ForInStep to bring the interpreter implementation closer
to the turbofan implementation. Also required to flatten out the
cache parameters into the interpreter frame for de-opt.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1531693002
Cr-Commit-Position: refs/heads/master@{#32986}
Adds support for loading and storing lookup variables.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1524803003
Cr-Commit-Position: refs/heads/master@{#32913}
Adds implementation and tests for CreateObjectLiteral, CreateArrayLiteral and CreateRegExpLiteral
to bytecode graph builder. Also changes these bytecodes to expect three operands instead of using
accumulator to pass one of the operands. This is done to avoid looking into the earlier nodes to
fetch operands in the bytecode graph builder. Also adds support for wide variant of these
bytecodes to bytecode generator and bytecode graph builder.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1503963002
Cr-Commit-Position: refs/heads/master@{#32710}
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}
