generate-bytecode-expectations is a tool intended to work together
with test/cctest/test-bytecode-generator.cc in order to produce a
meaningful diff between testcases and the actual bytecode being emitted.
It does so by parsing and compiling Javascript to bytecode,
constructing the same data structure in the testcase and then running a
textual diff between the expected (i.e. the one encoded in the unit test)
and actual (i.e. the one built from the compiler output) representation.
This commit is a first step in this direction, achieving just the first
half of what we desire. At the moment, bytecodechecker can:
* take a code snippet from the command line and emit the expected structure.
* adhere to the same formatting rules of the test cases
(this one is important for text diff and for copy and pasting too)
Still to do:
* parse unit tests:
+ extract code snippets
+ indent the code to match the input test case
+ allow flexibility in the input format
+ try to recognize and work around some macro magic (i.e. REPEAT_127)
* emit the representation of the constant pool and handlers vector
* run a textual diff
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1671863002
Cr-Commit-Position: refs/heads/master@{#33863}
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}
Reason for revert:
Must revert for now due to chromium api natives issues.
Original issue's description:
> Type Feedback Vector lives in the closure
>
> (RELAND: the problem before was a missing write barrier for adding the code
> entry to the new closure. It's been addressed with a new macro instruction
> and test. The only change to this CL is the addition of two calls to
> __ RecordWriteCodeEntryField() in the platform CompileLazy builtin.)
>
> We get less "pollution" of type feedback if we have one vector per native
> context, rather than one for the whole system. This CL moves the vector
> appropriately.
>
> We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
> vector actually lives in the first slot of the literals array (indeed there is
> great commonality between those arrays, they can be thought of as the same
> thing). So we make greater effort to ensure there is a valid literals array
> after compilation.
>
> This meant, for performance reasons, that we needed to extend
> FastNewClosureStub to support creating closures with literals. And ultimately,
> it drove us to move the optimized code map lookup out of FastNewClosureStub
> and into the compile lazy builtin.
>
> The heap change is trivial so I TBR Hannes for it...
> Also, Yang has had a look at the debugger changes already and approved 'em. So he is TBR style too.
> And Benedikt reviewed it as well.
>
> TBR=hpayer@chromium.org, yangguo@chromium.org, bmeurer@chromium.org
>
> BUG=
>
> Committed: https://crrev.com/bb31db3ad6de16f86a61f6c7bbfd3274e3d957b5
> Cr-Commit-Position: refs/heads/master@{#33741}
TBR=bmeurer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review URL: https://codereview.chromium.org/1670813005
Cr-Commit-Position: refs/heads/master@{#33766}
Adds a new runtime function, %DefineDataPropertyInLiteral, which
takes a fifth argument specifying whether the property and value
are syntactically such that the value is a function (or class)
literal that should have its name set at runtime.
The new runtime call also allows us to eliminate the now-redundant
%DefineClassMethod runtime function.
This should get much less ugly once we can desugar the "dynamic"
part of object literals in the parser (but that work is currently
blocked on having a performant way of desugaring literals).
BUG=v8:3699, v8:3761
LOG=n
Review URL: https://codereview.chromium.org/1626423003
Cr-Commit-Position: refs/heads/master@{#33756}
(RELAND: the problem before was a missing write barrier for adding the code
entry to the new closure. It's been addressed with a new macro instruction
and test. The only change to this CL is the addition of two calls to
__ RecordWriteCodeEntryField() in the platform CompileLazy builtin.)
We get less "pollution" of type feedback if we have one vector per native
context, rather than one for the whole system. This CL moves the vector
appropriately.
We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
vector actually lives in the first slot of the literals array (indeed there is
great commonality between those arrays, they can be thought of as the same
thing). So we make greater effort to ensure there is a valid literals array
after compilation.
This meant, for performance reasons, that we needed to extend
FastNewClosureStub to support creating closures with literals. And ultimately,
it drove us to move the optimized code map lookup out of FastNewClosureStub
and into the compile lazy builtin.
The heap change is trivial so I TBR Hannes for it...
Also, Yang has had a look at the debugger changes already and approved 'em. So he is TBR style too.
And Benedikt reviewed it as well.
TBR=hpayer@chromium.org, yangguo@chromium.org, bmeurer@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1668103002
Cr-Commit-Position: refs/heads/master@{#33741}
This implements proper context switching while unwinding the stack due
to an exception being handled in interpreted code. The context under
which the handler is scoped is being preserved in a dedicated register
while the try-block is running. Both, the stack unwinding machinery as
well as the graph builder, restore the context from that register.
R=rmcilroy@chromium.org,bmeurer@chromium.org
BUG=v8:4674
LOG=n
Review URL: https://codereview.chromium.org/1665833002
Cr-Commit-Position: refs/heads/master@{#33733}
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}
Unifies the meaning of kRegCount8 and kRegCount16 across bytecodes.
Call and CallJSRuntime had a slightly different use of the register
count operand. From this change forth, register count operands are
always based off of the previous register operand.
BUG=v8:4280,v8:4675
LOG=N
Review URL: https://codereview.chromium.org/1659023002
Cr-Commit-Position: refs/heads/master@{#33707}
Adds implementation and tests for with statement to interprter.
BUG=v8:4280,v8:4684
LOG=N
Review URL: https://codereview.chromium.org/1656863002
Cr-Commit-Position: refs/heads/master@{#33705}
This clears the currently pending message object whenever a try-block or
a finally-block is being entered in interpreted code. The intention is
to avoid memory leaks introduced by the message object. Also the message
object is being restored when a finally-block exits.
R=rmcilroy@chromium.org
TEST=cctest/test-heap/MessageObjectLeak
BUG=v8:4674
LOG=n
Review URL: https://codereview.chromium.org/1651993002
Cr-Commit-Position: refs/heads/master@{#33704}
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}
String wrappers (new String("foo")) are special objects: their string
characters are accessed like elements, and they also have an elements
backing store. This used to require a bunch of explicit checks like:
if (obj->IsJSValue() && JSValue::cast(obj)->value()->IsString()) {
/* Handle string characters */
}
// Handle regular elements (for string wrappers and other objects)
obj->GetElementsAccessor()->Whatever(...);
This CL introduces new ElementsKinds for string wrapper objects (one for
fast elements, one for dictionary elements), which allow folding the
special-casing into new StringWrapperElementsAccessors.
No observable change in behavior is intended.
Review URL: https://codereview.chromium.org/1612323003
Cr-Commit-Position: refs/heads/master@{#33616}
This translates the exception handler table attached to a bytecode array
correctly into exceptional projections within the TurboFan graph. We
perform an abstract simulation of handlers that are being entered and
exited by the bytecode iteration to track the correct handler for each
node.
R=oth@chromium.org
BUG=v8:4674
LOG=n
Review URL: https://codereview.chromium.org/1641723002
Cr-Commit-Position: refs/heads/master@{#33580}
Reason for revert:
Bug: failing to use write barrier when writing code entry into closure.
Original issue's description:
> Reland of Type Feedback Vector lives in the closure
>
> (Fixed a bug found by nosnap builds.)
>
> We get less "pollution" of type feedback if we have one vector per native
> context, rather than one for the whole system. This CL moves the vector
> appropriately.
>
> We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
> vector actually lives in the first slot of the literals array (indeed there is
> great commonality between those arrays, they can be thought of as the same
> thing). So we make greater effort to ensure there is a valid literals array
> after compilation.
>
> This meant, for performance reasons, that we needed to extend
> FastNewClosureStub to support creating closures with literals. And ultimately,
> it drove us to move the optimized code map lookup out of FastNewClosureStub
> and into the compile lazy builtin.
>
> The heap change is trivial so I TBR Hannes for it...
>
> TBR=hpayer@chromium.org
> BUG=
>
> Committed: https://crrev.com/d984b3b0ce91e55800f5323b4bb32a06f8a5aab1
> Cr-Commit-Position: refs/heads/master@{#33548}
TBR=bmeurer@chromium.org,yangguo@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review URL: https://codereview.chromium.org/1643533003
Cr-Commit-Position: refs/heads/master@{#33556}
(Fixed a bug found by nosnap builds.)
We get less "pollution" of type feedback if we have one vector per native
context, rather than one for the whole system. This CL moves the vector
appropriately.
We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
vector actually lives in the first slot of the literals array (indeed there is
great commonality between those arrays, they can be thought of as the same
thing). So we make greater effort to ensure there is a valid literals array
after compilation.
This meant, for performance reasons, that we needed to extend
FastNewClosureStub to support creating closures with literals. And ultimately,
it drove us to move the optimized code map lookup out of FastNewClosureStub
and into the compile lazy builtin.
The heap change is trivial so I TBR Hannes for it...
TBR=hpayer@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1642613002
Cr-Commit-Position: refs/heads/master@{#33548}
Introduces the concept of transfer direction to register operands. This
enables the register translator to emit exactly the moves that a
bytecode having it's register operands translated needs.
BUG=v8:4280,v8:4675
LOG=N
Review URL: https://codereview.chromium.org/1633153002
Cr-Commit-Position: refs/heads/master@{#33544}
Reason for revert:
FAilure on win32 bot, need to investigate webkit failures.
Original issue's description:
> Type Feedback Vector lives in the closure
>
> We get less "pollution" of type feedback if we have one vector per native
> context, rather than one for the whole system. This CL moves the vector
> appropriately.
>
> We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
> vector actually lives in the first slot of the literals array (indeed there is
> great commonality between those arrays, they can be thought of as the same
> thing). So we make greater effort to ensure there is a valid literals array
> after compilation.
>
> This meant, for performance reasons, that we needed to extend
> FastNewClosureStub to support creating closures with literals. And ultimately,
> it drove us to move the optimized code map lookup out of FastNewClosureStub
> and into the compile lazy builtin.
>
> The heap change is trivial so I TBR Hannes for it...
>
> TBR=hpayer@chromium.org
>
> BUG=
>
> Committed: https://crrev.com/a5200f7ed4d11c6b882fa667da7a1864226544b4
> Cr-Commit-Position: refs/heads/master@{#33518}
TBR=bmeurer@chromium.org,akos.palfi@imgtec.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review URL: https://codereview.chromium.org/1632993003
Cr-Commit-Position: refs/heads/master@{#33520}
We get less "pollution" of type feedback if we have one vector per native
context, rather than one for the whole system. This CL moves the vector
appropriately.
We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
vector actually lives in the first slot of the literals array (indeed there is
great commonality between those arrays, they can be thought of as the same
thing). So we make greater effort to ensure there is a valid literals array
after compilation.
This meant, for performance reasons, that we needed to extend
FastNewClosureStub to support creating closures with literals. And ultimately,
it drove us to move the optimized code map lookup out of FastNewClosureStub
and into the compile lazy builtin.
The heap change is trivial so I TBR Hannes for it...
TBR=hpayer@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1563213002
Cr-Commit-Position: refs/heads/master@{#33518}
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}
The current support for try-catch in the interpreter can handle most of
the cases appearing in our test suite. Also the flag in question did not
detect try-finally constructs. This removes the flag and instead extends
the test expectations.
R=rmcilroy@chromium.org
BUG=v8:4674
LOG=n
Review URL: https://codereview.chromium.org/1631593003
Cr-Commit-Position: refs/heads/master@{#33494}
Change the interpreter to always store the current context in the frame's
context slot instead of the function context. This makes it possible to
restore the correct context during deopt.
BUG=v8:4678,v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1604923002
Cr-Commit-Position: refs/heads/master@{#33477}
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}
This models function local control flow through try-finally constructs
using a token dispatch mechanism. All paths through the finally block
are assigned a token, at the end of the finally block a switch construct
dispatches according to this token.
R=oth@chromium.org,rmcilroy@chromium.org
BUG=v8:4674
LOG=n
Review URL: https://codereview.chromium.org/1613443002
Cr-Commit-Position: refs/heads/master@{#33465}
Break and continue operations need to pop the context chain to the
correct context before jumping to the target.
BUG=v8:4280,v8:4678
LOG=N
Review URL: https://codereview.chromium.org/1618693002
Cr-Commit-Position: refs/heads/master@{#33464}
This fixes the broken return address when the exception handler within
interpreted bytecode is being entered via stack unwinding. The address
in question will never actually be taken, but our stack walker uses this
address to determine whether a frame is interpreted.
R=rmcilroy@chromium.org
TEST=cctest/test-interpreter/InterpreterTryCatch
BUG=v8:4674
LOG=n
Review URL: https://codereview.chromium.org/1615063002
Cr-Commit-Position: refs/heads/master@{#33463}
This implements a first prototype of stack unwinding for interpreted
frames. The unwinding machinery performs a range-based lookup in the
given handler table and potentially continues dispatching at the handler
offset. Note that this does not yet correctly restore the context to the
correct value when the handler is being entered.
R=rmcilroy@chromium.org,oth@chromium.org
BUG=v8:4674
LOG=n
Review URL: https://codereview.chromium.org/1605633003
Cr-Commit-Position: refs/heads/master@{#33414}
This removes the above flag definition. The flag is no longer needed as
the default implementation is more than capable of faking presence of
handling of try-catch and try-finally constructs by now.
R=rmcilroy@chromium.org
BUG=v8:4674
LOG=n
Review URL: https://codereview.chromium.org/1603063003
Cr-Commit-Position: refs/heads/master@{#33402}
This implements a first version of exception handler table construction
within the interpreter. Note that the local control flow for try-catch
and try-finally statements is still off, and also stack unwinding does
not yet respect interpreter frames. But generated handler tables should
be populated correctly already.
R=oth@chromium.org
BUG=v8:4674
LOG=n
Review URL: https://codereview.chromium.org/1607433005
Cr-Commit-Position: refs/heads/master@{#33400}
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}
Fixes a bug where the context would be popped before labeled block break target
location.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1601153002
Cr-Commit-Position: refs/heads/master@{#33388}
Now that we support eval in Ignition, remove the fallback for eval checks
and make the flag only fallback on catch blocks.
BUG=v8:4280,v8:4676
LOG=N
Review URL: https://codereview.chromium.org/1595223004
Cr-Commit-Position: refs/heads/master@{#33384}
VisitObjectLiteral has two parts. First it creates a literal and then
sets properties or accessor properties. Setting properties requires a
runtime call and it expects the literal object which was created in the
first part is contiguous with other registers it allocates. Since these
are allocated in a different scope they are not always contiguous.
This causes problems with mjsunit/setter-on-constructor-prototype.js.
This cl fixes by allocating contiguous registers in the inner scope.
Literal value is copied into the newly allocated register so that all
the required registers are always contiguous.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1588903002
Cr-Commit-Position: refs/heads/master@{#33371}
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}
Adds support for variable and function declarations in lookup slots to the
interpreter.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1583783003
Cr-Commit-Position: refs/heads/master@{#33355}
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}
Removes assignment hazard scope. Reverts back to the naive scheme of
allocating a temporary for every variable load. It was decided to revert it
because the current implementation does not handle logical expressions,
ternary operators, visiting objects in named/keyed loads. Also, we wanted
to evaluate alternate approaches and choose one when we have a mechanism
to measure performance.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1576403004
Cr-Commit-Position: refs/heads/master@{#33269}
Adds support for LOOKUP_SLOT_CALL calls to the interpreter. Also changes
VisitCall to keep callee and reciever consecutive to avoid register
shuffles when performing LOOKUP_SLOT_CALL calls. Adds tests for the
interpreter and bytecode graph generator.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1568323002
Cr-Commit-Position: refs/heads/master@{#33237}
This patch moves the semantics of 'const' in sloppy mode to match those
in strict mode, that is, const makes lexical (let-like) bindings, must
have an initializer, and does not create properties of the global object.
R=adamk
LOG=Y
BUG=v8:3305
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
Review URL: https://codereview.chromium.org/1571873004
Cr-Commit-Position: refs/heads/master@{#33218}
Fixed a bug in VisitForInAssignment. After visiting the object the value
to be stored was not loaded back to the accumulator. Also added two tests
to check this case.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1571753002
Cr-Commit-Position: refs/heads/master@{#33188}
Adds support for calling eval to the interpreter.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1508293003
Cr-Commit-Position: refs/heads/master@{#33184}
