This moves the responsibility of preparing full-codegen code with
deoptimization support into the backends. This avoids generating such
code when optimization can be done directly from existing bytecode.
R=bmeurer@chromium.org
BUG=v8:4280
LOG=n
Review URL: https://codereview.chromium.org/1883403002
Cr-Commit-Position: refs/heads/master@{#35517}
Removes skips for two tests that no longer fail on windows system.
Updates description of another failing test with more details.
BUG=v8:4280,v8:4680
LOG=N
Review URL: https://codereview.chromium.org/1878893004
Cr-Commit-Position: refs/heads/master@{#35475}
This change implements switch as a balanced if/else tree or break table or
hybrid. A lot of asm.js modules are expected to extensively use switch
alongside function tables that can benefit from a better implementation.
BUG=v8:4203
TEST=mjsunit/asm-wasm
R=titzer@chromium.org,bradnelson@chromium.org,ahaas@chromium.org
LOG=N
Review URL: https://codereview.chromium.org/1838973002
Cr-Commit-Position: refs/heads/master@{#35455}
Introduce a ResumeGeneratorTrampoline, which does the actual stack state
reconstruction (currently always restores a fullcodegen frame), and
introduce appropriate TurboFan builtins for %GeneratorPrototype%.next,
%GeneratorPrototype%.return and %GeneratorPrototype%.throw based on
this native builtin.
Also unify the flooding in case of step-in to always work based on
JSFunction and remove the special casing for JSGeneratorObject.
R=mstarzinger@chromium.org, neis@chromium.orgTBR=rossberg@chromium.org
BUG=chromium:513471
LOG=n
Review URL: https://codereview.chromium.org/1865833002
Cr-Commit-Position: refs/heads/master@{#35283}
In simplified numbering, we make sanity checks based on types (e.g.,
NumberSubtract should take numbers as inputs), but this can be
violated if optimization passes make types less precise.
In this CL, we fix load elimination to make sure that types are
smaller in the store -> load elimination by taking an intersection
of the load's type with the store value's type and inserting a guard
with that type. Note that the load type comes from type feedback, so
it can be disjoint from the stored value type (in that case, this
must be dead code because the map chack for the load should prevent
us from using the stored value).
BUG=chromium:599412
LOG=n
Review URL: https://codereview.chromium.org/1857133003
Cr-Commit-Position: refs/heads/master@{#35259}
Debugger fetches the return value of a function when we break at return.
Interpreter holds the return value in accumulator. This is not stored in a
specified location on stack and hence it is not possible to look it up from
stack similar to full-codegen or optimized frames. This cl adds support to
store the value of accumulator on debug breaks. The value of accumulator is
passed to the runtime function and is then stored in thread local data.
Also changes full-codegen implementation to match that of ignition.
The return value from full-codegen is also stored in thread local data.
The return value is fetched directly thread local data instead of
finding it by iterating over frames.
BUG=v8:4280, v8:4690
LOG=N
Review URL: https://codereview.chromium.org/1842683002
Cr-Commit-Position: refs/heads/master@{#35127}
In JavaScript code and stubs, JSSP mirrors the CSP but may be unaligned.
But in WASM code only CSP is used, like native code, and it must be
aligned.
Calls into WASM from JS need to carefully align the C stack
pointer (csp) and restore the previous JSSP, while calls from WASM
to JS need to compute a new JSSP and restore their CSP after the
call.
R=ahaas@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1811283003
Cr-Commit-Position: refs/heads/master@{#35096}
Makes --ignition cause eager compilation if we aren't building the startup
snapshot.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1811553003
Cr-Commit-Position: refs/heads/master@{#35066}
Reason for revert:
[Sheriff] Seems to break nosnap debug:
https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap%20-%20debug/builds/6019
Original issue's description:
> [Interpreter] Adds support to fetch return value on break at return.
>
> Debugger fetches the return value of a function when we break at return.
> Interpreter holds the return value in accumulator. This is not stored in a
> specified location on stack and hence it is not possible to look it up from
> stack similar to full-codegen or optimized frames. This cl adds support to
> store the value of accumulator on debug breaks. The value of accumulator is
> passed to the runtime function and is then stored in thread local data.
>
> Also changes full-codegen implementation to match that of ignition.
> The return value from full-codegen is also stored in thread local data.
> The return value is fetched directly thread local data instead of
> finding it by iterating over frames.
>
> BUG=v8:4280, v8:4690
> LOG=N
>
> Committed: https://crrev.com/fb65527b75754bcf3b173f16f5d0b04a1c6d9b99
> Cr-Commit-Position: refs/heads/master@{#35060}
TBR=rmcilroy@chromium.org,yangguo@chromium.org,weiliang.lin@intel.com,balazs.kilvady@imgtec.com,jyan@ca.ibm.com,mythria@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4280, v8:4690
Review URL: https://codereview.chromium.org/1834733002
Cr-Commit-Position: refs/heads/master@{#35065}
Debugger fetches the return value of a function when we break at return.
Interpreter holds the return value in accumulator. This is not stored in a
specified location on stack and hence it is not possible to look it up from
stack similar to full-codegen or optimized frames. This cl adds support to
store the value of accumulator on debug breaks. The value of accumulator is
passed to the runtime function and is then stored in thread local data.
Also changes full-codegen implementation to match that of ignition.
The return value from full-codegen is also stored in thread local data.
The return value is fetched directly thread local data instead of
finding it by iterating over frames.
BUG=v8:4280, v8:4690
LOG=N
Review URL: https://codereview.chromium.org/1818873003
Cr-Commit-Position: refs/heads/master@{#35060}
Fixes CopyBytecodeArray to set the interrupt_budget field.
BUG=v8:4280,v8:4690
LOG=N
Review URL: https://codereview.chromium.org/1809123003
Cr-Commit-Position: refs/heads/master@{#34982}
Add missing conversions from other types to f32 in fround.
Restrict fround() to only float, double, signed, unsigned (no unions / intish).
Restrict Bitwise operations to intish, particularly |0, when not applied to a foreign function.
Adding more exhaustive tests of stdlib Math, move to a separate file.
Adding tests of interesting values for the stdlib asm.js functions.
BUG= https://bugs.chromium.org/p/v8/issues/detail?id=4203
TEST=test-asm-validator,asm-wasm
R=titzer@chromium.org,rossberg@chromium.org
LOG=N
Review URL: https://codereview.chromium.org/1804243003
Cr-Commit-Position: refs/heads/master@{#34967}
Both of them shipped in Chrome 49 without incident.
Also move relevant tests from harmony/ to es6/.
Review URL: https://codereview.chromium.org/1815773002
Cr-Commit-Position: refs/heads/master@{#34964}
In case when F inlined normal call to G which tail calls H we should not write translation for G for the tail call site.
Otherwise we will see G in a stack trace inside H.
This CL also enables all existing tests related to ES6 tail call elimination and adds more combinations.
TBR=bmeurer@chromium.org
BUG=v8:4698
LOG=N
Committed: https://crrev.com/689980f7d4dfd4c29492f616d7b616b86ec9af91
Cr-Commit-Position: refs/heads/master@{#34830}
Review URL: https://codereview.chromium.org/1780043004
Cr-Commit-Position: refs/heads/master@{#34920}
In case when F inlined normal call to G which tail calls H we should not write translation for G for the tail call site.
Otherwise we will see G in a stack trace inside H.
This CL also enables all existing tests related to ES6 tail call elimination.
TBR=bmeurer@chromium.org
BUG=v8:4698
LOG=N
Review URL: https://codereview.chromium.org/1780043004
Cr-Commit-Position: refs/heads/master@{#34830}
The feature was removed from the bots a while ago. It was
superseeded by the flaky-test detection which reruns tests.
Remaining tests still marked as flaky most certainly pass
since a while.
Referencing all the bugs whose expectations lines get
removed by this.
BUG=v8:3838,v8:3525,v8:3125
LOG=n
Review URL: https://codereview.chromium.org/1802983002
Cr-Commit-Position: refs/heads/master@{#34804}
We may not emit bytecode for the evaluation of the to-be-returned
expression. In that case we cannot set two return positions for a return
statement (one before and one after the expression evaluation). This
sets the interpreter apart from full-codegen.
Make sure that we always have the second of the two return positions.
Note that we end up with separate test cases for ignition and FCG.
R=rmcilroy@chromium.org, vogelheim@chromium.org
BUG=v8:4690
LOG=N
Review URL: https://codereview.chromium.org/1801473003
Cr-Commit-Position: refs/heads/master@{#34771}
Modules already have a separate entrypoint into the engine (at the moment,
this is v8::ScriptCompiler::CompileModule, though that will change to
something like ParseModule). This meant that requiring a commandline flag
simply added an extra complexity burden on embedders. By removing the v8
flag, this lets embedders use their own flagging mechanism (such as d8's
"--module", or Blink's RuntimeEnabledFeatures) to control whether
modules are to be used.
Also remove old modules tests that were being skipped (since they test
very old, pre-ES2015 modules syntax).
R=littledan@chromium.org
BUG=v8:1569, chromium:594639
LOG=y
Review URL: https://codereview.chromium.org/1804693002
Cr-Commit-Position: refs/heads/master@{#34764}
FullCodegen generates 2 statement positions for the loop init block, like so:
for(var i = 0; i....
^ ^
This change removes the first of those, updates unit tests,
and removes text expectations for Ignition.
---
An alternative would be to emulate the existing behaviour in Ignition, but:
- The new behaviour seems more logical,
- Ignition generates no bytecodes for the 'var', meaning there is no code position to attach the break position to.
BUG=v8:4690
LOG=Y
Review URL: https://codereview.chromium.org/1784883002
Cr-Commit-Position: refs/heads/master@{#34717}
This is because compiler.cc is awesome. There are cases where we do not
yet have a SharedFunctionInfo that can tell us whether we are compiling
a generator function, we query the FunctionLiteral instead.
R=rmcilroy@chromium.org
BUG=v8:4681
LOG=n
Review URL: https://codereview.chromium.org/1780193002
Cr-Commit-Position: refs/heads/master@{#34677}
This ensures our optimizing compilers as well as the interpreter are
never tasked with compiling the generator-resuming builtin methods. The
corresponding intrinsics for those methods are not supported and it is
not possible to provide a C++ reference implementation for them. We do
this by assigning builtin function ids to them that we can recognize
during the compiler dispatch.
Note that this also affects the interpreter, because methods having a
builtin function id assigned are not interpreted ({function_data} field
is overlapping). If this ever changes we can still do an early check in
the compiler dispatch (similar to the optimizing compilers) easily.
This applies to the following methods:
- Generator.prototype.next (calls Runtime_GeneratorNext).
- Generator.prototype.return (calls Runtime_GeneratorReturn).
- Generator.prototype.throw (calls Runtime_GeneratorThrow).
R=neis@chromium.org
BUG=v8:4681
LOG=n
Review URL: https://codereview.chromium.org/1779123003
Cr-Commit-Position: refs/heads/master@{#34675}
This ensures the interpreter is not tasked with compiling generator
functions. It currently does not support suspending activations at
yielding points, but we still want to be able to activate it for the
rest of JavaScript in the meantime.
R=rmcilroy@chromium.org
BUG=v8:4681
LOG=n
Review URL: https://codereview.chromium.org/1782013002
Cr-Commit-Position: refs/heads/master@{#34672}
The current implementation does not consider the case when the context of
the control scope and the current context differ. It is possible that they are
different in some cases for example: with statements. This cl fixes this.
BUG=v8:4280,v8:4680
LOG=N
Review URL: https://codereview.chromium.org/1768123002
Cr-Commit-Position: refs/heads/master@{#34609}
This mechanism was used to ensure that functions ended up as constants on the map of prototypes defined using object literals, e.g.,:
function.prototype = {
method: function() { ... }
}
Nowadays we treat prototypes specially, and make all their functions constants when an object turns prototype. Hence this special custom code isn't necessary anymore.
This also affects boilerplates that do not become prototypes. Their functions will not be constants but fields instead. Calling their methods will slow down. However, multiple instances of the same boilerplate will stay monomorphic. We'll have to see what the impact is for such objects, but preliminary benchmarks do not show this as an important regression.
BUG=chromium:593008
LOG=n
Review URL: https://codereview.chromium.org/1772423002
Cr-Commit-Position: refs/heads/master@{#34602}
BailoutId points to the next bytecode in the bytecode array. Code offset
is set to one less than the bail out id. This would point to the end of the
current instruction. Since we use it only for summarizing the frame and to
compute the source position, it should be safe to set it to the end of current
instruction.
BUG=v8:4280, v8:4689
LOG=N
Review URL: https://codereview.chromium.org/1763783003
Cr-Commit-Position: refs/heads/master@{#34580}
Frames entering of inside wasm don't have a function or context argument.
Adding distinct wasm frame and function types to express this.
Fixes a GC issue on several embenchen wasm tests, reenabling them.
BUG= https://code.google.com/p/v8/issues/detail?id=4203
TEST=mjsunit/wasm/embenchen
R=titzer@chromium.org,aseemgarg@chromium.org,jfb@chromium.org,yangguo@chromium.org
LOG=N
Review URL: https://codereview.chromium.org/1764603003
Cr-Commit-Position: refs/heads/master@{#34476}
ES2015 generally bans FunctionDeclarations in positions which expect a Statement,
as opposed to a StatementListItem, such as a FunctionDeclaration which constitutes
the body of a for loop. However, Annex B 3.2 and 3.4 make exceptions for labeled
function declarations and function declarations as the body of an if statement in
sloppy mode, in the latter case specifying that the semantics are as if the
function declaration occurred in a block. Chrome has historically permitted
further extensions, for the body of any flow control construct.
This patch addresses both the syntactic and semantic mismatches between V8 and
the spec. For the semantic mismatch, function declarations as the body of if
statements change from unconditionally hoisting in certain cases to acquiring
the sloppy mode function in block semantics (based on Annex B 3.3). For the
extra syntax permitted, this patch adds a flag,
--harmony-restrictive-declarations, which excludes disallowed function declaration
cases. A new UseCounter, LegacyFunctionDeclaration, is added to count how often
function declarations occur as the body of other constructs in sloppy mode. With
this patch, the code generally follows the form of the specification with respect
to parsing FunctionDeclarations, rather than allowing them in arbitrary Statement
positions, and makes it more clear where our extensions occur.
BUG=v8:4647
R=adamk
LOG=Y
Review URL: https://codereview.chromium.org/1757543003
Cr-Commit-Position: refs/heads/master@{#34470}
The function literal consists of a list of statements. Each statement
is associated with a statement position including break location. The
only exception to this rule is when the function immediately throws if
scope resolution found an illegal redeclaration. Make sure that we add a
break location for this case as well. The debugger relies on this.
R=bmeurer@chromium.org, vogelheim@chromium.org
BUG=v8:4690
LOG=N
Review URL: https://codereview.chromium.org/1759603002
Cr-Commit-Position: refs/heads/master@{#34422}
Adds the translation from optimized frame to bytecode offset
in FrameSummary. For interpreter, the bailout id represents the bytecode
array offset. So we can directly use the bailout id as the code offset
in the FrameSummary. Also updates mjsunit.status with more information
about failing tests.
BUG=v8:4280, v8:4689
LOG=N
Review URL: https://codereview.chromium.org/1740753002
Cr-Commit-Position: refs/heads/master@{#34393}
We used to emit debug break location on block entry. This cannot be
ported to the interpreted as we do not emit bytecode for block entry.
This made no sense to begin with though, but accidentally added
break locations for var declarations.
With this change, the debugger no longer breaks at var declarations
without initialization. This is in accordance with the fact that the
interpreter does not emit bytecode for uninitialized var declarations.
Also fix the bytecode to match full-codegen's behavior wrt return
positions:
- there is a break location before the return statement, with the source
position of the return statement.
- right before the actual return, there is another break location. The
source position points to the end of the function.
R=rmcilroy@chromium.org, vogelheim@chromium.orgTBR=rossberg@chromium.org
BUG=v8:4690
LOG=N
Review URL: https://codereview.chromium.org/1744123003
Cr-Commit-Position: refs/heads/master@{#34388}
The CompareICStub produces an untagged raw word value, which has to be
translated to true or false manually in the TurboFan code. But for lazy
bailout after the CompareIC, we immediately go back to fullcodegen or
Ignition with the raw value, to a location where both fullcodegen and
Ignition expect a boolean value, which might crash or in the worst case
(depending on the exact computation inside the CompareIC) could lead to
arbitrary memory access.
Short-term fix is to use the proper runtime functions (unified with the
interpreter now) for comparisons. Next task is to provide optimized
versions of these based on the CodeStubAssembler, which can then be used
via code stubs in TurboFan or directly in handlers in the interpreter.
R=mstarzinger@chromium.org
BUG=v8:4788
LOG=n
Review URL: https://codereview.chromium.org/1738153002
Cr-Commit-Position: refs/heads/master@{#34335}
The %_Call intrinsic (if supported by the compiler) is lowered directly
to the Call builtin and thus throws a TypeError if the target is not
callable. The %Call runtime function also eventually calls into the Call
builtin, but had an early abort if the target is not a JSReceiver, which
is unnecessary and leads to various test failures for Ignition.
R=mvstanton@chromium.org
Review URL: https://codereview.chromium.org/1727833006
Cr-Commit-Position: refs/heads/master@{#34316}
The treatment of different undetectable objects was inconsistent after
the latest changes to the undetectable bit in the maps. Given two
different undetectable JSObjects a and b, a monomorphic CompareIC would
say false for a == b, while the rest of the system (including the
generic case for the CompareIC) would say true.
The fix is rather straight-forward: We just go generic on a CompareIC
once we see an undetectable JSObject.
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/1735863004
Cr-Commit-Position: refs/heads/master@{#34315}
By now the deprecation of strong mode is far enough along that the
support present in the interpreter matches the support in the other
compilers. Special expectations aren't needed anymore.
R=rmcilroy@chromium.org
Review URL: https://codereview.chromium.org/1738653003
Cr-Commit-Position: refs/heads/master@{#34293}
Handles stack overflow in interpreter.
1. When visiting function literal, if the shared function
info cannot be found we should return a stack overflow.
2. When visiting the ast graph, if stack overflow happens
then all the ast nodes are not visited, so we need to have
appropriate handling in the AccumulatorResultScope and
RegisterResultScope.
3. MakeBytecode should not return a suceess unconditionally.
If there is a stack overflow, it should return false, so
RangeError can be thrown.
BUG=v8:4280,v8:4680
LOG=N
Review URL: https://codereview.chromium.org/1721983005
Cr-Commit-Position: refs/heads/master@{#34282}
This fixes a corner case that triggered an assert in full-codegens
operand stack depth tracking. We stop pushing operands if we overflow
the C-stack while iterating the AST. This makes the tracking go out of
sync before we fully returned from the tree traversal, at which point
the thrown RangeError will abort compilation.
R=ishell@chromium.org
TEST=mjsunit/regress/regress-crbug-589472
BUG=chromium:589472
LOG=n
Review URL: https://codereview.chromium.org/1732903002
Cr-Commit-Position: refs/heads/master@{#34255}
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}
These macro operators represent a conditional eager deoptimization exit
without explicit branching, which greatly reduces overhead of both
scheduling and register allocation, and thereby greatly reduces overall
compilation time, esp. when there are a lot of eager deoptimization
exits.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1721103003
Cr-Commit-Position: refs/heads/master@{#34239}
The Proxy enumerate trap and Reflect.enumerate are removed from the
ES2016 draft specification. This patch removes the Reflect.enumerate
function, and a follow-on patch will be responsible for the Proxy
trap changes.
R=adamk
LOG=Y
BUG=v8:4768
Review URL: https://codereview.chromium.org/1721453002
Cr-Commit-Position: refs/heads/master@{#34196}
Adds a profiling counter to each BytecodeArray object, and adds
code to Jump and Return bytecode handlers to update this
counter by the size of the jump or the distance from the return
to the start of the function. This is more accurate than fullcodegen's
approach since it takes forward jumps into account as well as back-edges.
Modifies RuntimeProfiler to track ticks for interpreted frames.
Currently we use the SharedFunctionInfo::profiler_ticks() instead
of adding another to tick field to avoid adding another field to
BytecodeArray since SharedFunctionInfo::profiler_ticks() is only
used by Crankshaft otherwise so we shouldn't need both for
BUG=v8:4689
LOG=N
Review URL: https://codereview.chromium.org/1707693003
Cr-Commit-Position: refs/heads/master@{#34166}
Implements iterator finalisation by desugaring for-of loops with an additional try-finally wrapper. See comment in parser.cc for details.
Also improved some AST printing facilities while there.
@Ross, I had to disable the bytecode generation test for for-of, because it got completely out of hand after this change (the new bytecode has 150+ lines). See the TODO that I assigned to you.
Patch set 1 is WIP patch by Georg (http://crrev.com/1695583003), patch set 2 relative changes.
@Georg, FYI, I changed the following:
- Moved try-finally out of the loop body, for performance, and in order to be able to handle `continue` correctly.
- Fixed scope management in ParseForStatement, which was the cause for the variable allocation failure.
- Fixed pre-existing zone initialisation bug in rewriter, which caused the crashes.
- Enabled all tests, adjusted a few others, added a couple more.
BUG=v8:2214
LOG=Y
Review URL: https://codereview.chromium.org/1695393003
Cr-Commit-Position: refs/heads/master@{#34111}
The reason:
Similar to the CL 31552 (https://codereview.chromium.org/1419573007).
The CL 33972 (https://codereview.chromium.org/1698783002) optimized some JS function in regress-crbug-242924 test case by TurboFan compiler.
But it will hit the known issue that X87 will change a sNaN to qNaN by default. And then it will fail when comparing the source (sNaN) Hole NaN and
the result (qNaN) which was expected to be a (sNaN) Hole NaN too.
BUG=
Review URL: https://codereview.chromium.org/1704313003
Cr-Commit-Position: refs/heads/master@{#34104}
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}
