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}
This fixes a corner case where the generator function of a suspended
generator has been marked for optimization. We assume the optimization
approach will cause a bailout because generators are not optimized. But
resuming is more resilient by always activating the unoptimized code.
R=neis@chromium.org,bmeurer@chromium.org
TEST=mjsunit/regress/regress-crbug-513471
BUG=chromium:513471
LOG=n
Review URL: https://codereview.chromium.org/1856683002
Cr-Commit-Position: refs/heads/master@{#35234}
This CL ensures that we build environments/frame states so that tail caller frame will never become topmost.
BUG=chromium:598998, v8:4698
LOG=N
Review URL: https://codereview.chromium.org/1849503002
Cr-Commit-Position: refs/heads/master@{#35188}
The HandlerCompiler did not properly handle the weird edge case when a
sloppy mode function was installed as an accessor on one of the value
wrapper prototypes and then accessed via a load from a primitive value.
In this case we just passed the primitive value untouched instead of
properly wrapping it first. The CallFunction builtin properly deals with
all the funny edge cases, so we use it instead of duplicating almost all
of the logic here (the performance difference is neglible).
R=verwaest@chromium.org
BUG=chromium:599073, v8:4413
LOG=n
Review URL: https://codereview.chromium.org/1845243005
Cr-Commit-Position: refs/heads/master@{#35187}
Fix and re-enable the flexible representation for Math.floor (which is used to
implement Math.ceil) and Math.round, which allows Math.floor and Math.round to
return double results instead of int32, and therefore allows values outside
the int32 range, especially -0 is now a valid result, which doesn't deopt.
Also port this feature to x64 and ia32 when the CPU supports the SSE4.1
extension.
This addresses all the known deoptimization loops related to Math.round
in the Kraken benchmark suite, and seems to also address most of the
deoptimization loops related to Math.floor in the Oort Online benchmark.
Drive-by-fix: Import the regression tests for the broken HMathFloorOfDiv
optimization that caused the initial revert of the feature (for arm64 only
back then).
BUG=chromium:476477,v8:2890,v8:4059
R=jarin@chromium.org
LOG=n
Review URL: https://codereview.chromium.org/1841513003
Cr-Commit-Position: refs/heads/master@{#35094}
It's been on since M49. Also moved tests from harmony -> es6,
one of which was merged with another test of the same name.
While moving stuff over to regexp.js, I also noticed that there
were unused calls to %FunctionSetName and %SetNativeFlag (those
calls are already handled by InstallGetter()).
Review URL: https://codereview.chromium.org/1838563003
Cr-Commit-Position: refs/heads/master@{#35076}
A bug in error printing meant that we failed to do proper type checks
before calling into C++ code, which could lead to RUNTIME_ASSERT
failures if methods are called on alternative receivers. This patch
adds the right type checks.
BUG=chromium:596718
LOG=Y
R=adamk
Review URL: https://codereview.chromium.org/1831053003
Cr-Commit-Position: refs/heads/master@{#35069}
Now that ES2015 const has shipped, in Chrome 49, legacy const declarations
are no more. This lets us remove a bunch of code from many parts of the
codebase.
In this patch, I remove parser support for generating legacy const variables
from const declarations. This also removes the special "illegal declaration"
bit from Scope, which has ripples into all compiler backends.
Also gone are any tests which relied on legacy const declarations.
Note that we do still generate a Variable in mode CONST_LEGACY in one case:
function name bindings in sloppy mode. The likely fix there is to add a new
Variable::Kind for this case and handle it appropriately for stores in each
backend, but I leave that for a later patch to make this one completely
subtractive.
Review URL: https://codereview.chromium.org/1819123002
Cr-Commit-Position: refs/heads/master@{#35002}
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}
This is necessary to ensure that "Called non callable" exception will get a proper message and stack trace even for calls at tail position.
BUG=chromium:595615, v8:4698
LOG=N
Review URL: https://codereview.chromium.org/1818003002
Cr-Commit-Position: refs/heads/master@{#34962}
Previously only JSFunctions seemed to be valid for toJSON, which doesn't
match the ES6 specification that allows any object with [[Call]]
internal method (i.e. any Callable in V8 terminology), including bound
functions and proxies.
BUG=chromium:595738, chromium:535408
R=yangguo@chromium.org
LOG=n
Review URL: https://codereview.chromium.org/1824533002
Cr-Commit-Position: refs/heads/master@{#34913}
This patch fixes two bugs in Array.prototype.concat in conjunction with
subclassing Arrays:
- Create a new property rather than calling Set when adding elements to
the output array. This means setters are not called.
- If there is an exception thrown from DefineProperty, propagate it
outwards properly, rather than swallowing it. This can occur, e.g., with
a Proxy as the new output array.
R=adamk
LOG=Y
BUG=chromium:595319
Review URL: https://codereview.chromium.org/1814933002
Cr-Commit-Position: refs/heads/master@{#34876}
Repair this to match what the runtime correctly does, by first checking if the
function is a constructor before we access the prototype.
R=verwaest@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1810953002
Cr-Commit-Position: refs/heads/master@{#34863}
Function declarations were previously permitted by V8 in many locations
which no ECMAScript specification allowed; the ECMAScript 2015 spec
enumerates a few locations (in blocks, as well as after labels and in
conditionals when in sloppy mode). This patch ships the flag to restrict
the usage of function declarations to those contexts.
R=adamk
LOG=Y
BUG=v8:4824
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
Review URL: https://codereview.chromium.org/1799233003
Cr-Commit-Position: refs/heads/master@{#34828}
The monomorphic case already carefully ensures that we don't try to use
a regular elements load stub on string wrapper elements. The polymorphic
path must perform an equivalent check.
BUG=chromium:594955
LOG=n
R=verwaest@chromium.org
Review URL: https://codereview.chromium.org/1806543002
Cr-Commit-Position: refs/heads/master@{#34807}
This part of Scope has existed since V8's initial check in, but from what
I can tell it's not required to implement "with". The only tests that
depend upon it are tests of the debugger and the Scope mirrors, but the
resulting test behavior after removing the bit still seems perfectly
reasonable to me. In fact, with the included fix for scope name collection,
the scope mirror is actually improved with this change.
As a bi-product, this fixes the attached bug, about the contains_with
bit having inconsistent values in some arrow function compilation
scenarios.
BUG=chromium:592353
LOG=n
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
Review URL: https://codereview.chromium.org/1804783002
Cr-Commit-Position: refs/heads/master@{#34802}
Array.prototype.concat did not work correct with complex elements on the
receiver or the prototype chain.
BUG=chromium:594574
LOG=y
Review URL: https://codereview.chromium.org/1804963002
Cr-Commit-Position: refs/heads/master@{#34798}
These flags have been on by default since version 4.9, which has been
in stable Chrome for over a week now, demonstrating that they're
here to stay.
Also moved the tests out of harmony/ and into es6/.
Review URL: https://codereview.chromium.org/1776683003
Cr-Commit-Position: refs/heads/master@{#34692}
When an Array subclass is used as the receiver for concat, or with
certain usages of @@species, the output that's constructed is of
a different type with new slow path logic. This slow path still
made references to elements, so it's important that bounds checking
for a too-long result still be done. This patch repairs that bounds
checking.
R=cbruni
LOG=Y
BUG=chromium:592340
Review URL: https://codereview.chromium.org/1782443002
Cr-Commit-Position: refs/heads/master@{#34636}
Reading the registers' values back from the FrameDescription
should use the same offset computation as storing them into it.
The offsets must also match what the deoptimizer expects, which
is rx at offset rx.code() * kDoubleSize, even if some registers
are not saved (leaving gaps).
BUG=v8:4800
LOG=n
R=danno@chromium.org
Review URL: https://codereview.chromium.org/1769833006
Cr-Commit-Position: refs/heads/master@{#34633}
The CharacterRange constructor checks the input for validity. However,
CharacterRange::Singleton also uses the constructor and may have
kEndMarker as input, causing the check to fail.
The solution is to move the check to CharacterRange::Range and
consistently use it across the code base.
R=jkummerow@chromium.org
BUG=chromium:593282
LOG=N
Review URL: https://codereview.chromium.org/1776013003
Cr-Commit-Position: refs/heads/master@{#34626}
After fixing the memory barrier for maps (https://codereview.chromium.org/1714513003), we are using a temp register for the map case. The temp register should not be aliased with the stored value (otherwise we perform the mem barrier check with a wrong value). This CL makes sure it is not aliased.
BUG=chromium:590074
LOG=n
Review URL: https://codereview.chromium.org/1775083002
Cr-Commit-Position: refs/heads/master@{#34607}
We cannot optimize away ToNumber conversions based on the Type that we
see in Crankshaft, as this might be the (unchecked or even pretruncated)
lower bound. We can only use the HType, which is based on the definition.
R=jkummerow@chromium.org
BUG=chromium:590989
LOG=n
Review URL: https://codereview.chromium.org/1757013002
Cr-Commit-Position: refs/heads/master@{#34445}
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 LoadBuffer operator that is used for asm.js heap access claims to
return only the appropriate typed array type, but out of bounds access
could make it return undefined. So far we tried to "repair" the graph
later if we see that our assumption was wrong, and for various reasons
that worked for some time. But now that wrong type information that is
propagated earlier is picked up appropriately and thus we generate wrong
code, i.e. we in the repro case we feed NaN into ChangeFloat64Uint32 and
thus get 2147483648 instead of 0 (with proper JS truncation).
This was always considered a temporary hack until we have a proper
asm.js pipeline, but since we still run asm.js through the generic
JavaScript pipeline, we have to address this now. Quickfix is to just
bailout from the pipeline when we see that the LoadBuffer type was
wrong, i.e. the result of LoadBuffer is not properly truncated and thus
undefined or NaN would be observable.
R=mstarzinger@chromium.org, jarin@chromium.org
BUG=chromium:589792
LOG=y
Review URL: https://codereview.chromium.org/1740123002
Cr-Commit-Position: refs/heads/master@{#34322}
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}
The Crankshaft fast case for String.fromCharCode() unconditionally
deoptimizes on all non-int32 inputs, even tho it would be perfectly
valid to just truncate the index to an int32.
R=ishell@chromium.org
BUG=chromium:587068
LOG=n
Review URL: https://codereview.chromium.org/1727873003
Cr-Commit-Position: refs/heads/master@{#34243}
