Before, just a string was thrown, so no stack trace was attached there.
Generated code from wasm does not grow by this change, we just pass a
message id to the respective (new) runtime function.
R=mstarzinger@chromium.org, titzer@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1874383002
Cr-Commit-Position: refs/heads/master@{#35664}
Also factor out test cases from test-run-machops.cc into test-run-load-store.cc
BUG=chromium:599717
LOG=Y
Review URL: https://codereview.chromium.org/1858323003
Cr-Commit-Position: refs/heads/master@{#35651}
Add support to optimize certain comparisons of typeof with known
strings to utilize the existing ObjectIs<Type> predicates. Also
add a new ObjectIsCallable, which is used to optimize the common
typeof x === "function" pattern.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1898653003
Cr-Commit-Position: refs/heads/master@{#35562}
These operators are really pure on the JavaScript level, and were only
part of the effect chain to make sure we don't accidentially schedule
them right after raw allocations, which is no longer an issue since we
now have the concept of atomic regions.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1893543004
Cr-Commit-Position: refs/heads/master@{#35552}
This patch correctly re-scopes inner scopes that can appear in do
expressions used as initializers to arrow parameters.
R=rossberg@chromium.org
BUG=v8:4904
LOG=N
Review URL: https://codereview.chromium.org/1887743002
Cr-Commit-Position: refs/heads/master@{#35542}
Usually, script compilation is expensive enough to warrant the extra
overhead of caching scripts immediatly.
BUG=chromium:588900
R=yangguo@chromium.org
LOG=n
Review URL: https://codereview.chromium.org/1890083002
Cr-Commit-Position: refs/heads/master@{#35527}
This prefixes the escape analysis flag with "experimental", thereby
making sure the flag in question is not being fuzzed. It will reduce
noise levels on ClusterFuzz again.
R=jarin@chromium.org
BUG=chromium:603653
LOG=n
Review URL: https://codereview.chromium.org/1894513002
Cr-Commit-Position: refs/heads/master@{#35521}
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}
Reason for revert:
performance impact
Original issue's description:
> Correctly annotate eval origin.
>
> There were a couple of issues with it:
> - interpreter is not supported
> - the source position was just accidentally correct for full-codegen
> - the eval origin could have been cached
>
> Also fixes a few other places to use AbstractCode.
>
> R=mstarzinger@chromium.org
>
> Committed: https://crrev.com/2f3a171adc9e620c2235bf0562145b9d4eaba66d
> Cr-Commit-Position: refs/heads/master@{#35257}
>
> Committed: https://crrev.com/ad4e8a27963b704bb70ec8bac0991c57296b1d16
> Cr-Commit-Position: refs/heads/master@{#35481}
TBR=mstarzinger@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1888013002
Cr-Commit-Position: refs/heads/master@{#35491}
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}
Reland of (https://codereview.chromium.org/1617503003)
* New atomic code stubs for x64, ia32, arm, arm64
* Add convenience functions JumpIfNotValidSmiValue, JumpIfUintNotValidSmiValue
to macro-assembler-ia32 (API based on x64 macro assembler)
* Remove runtime implementation of Atomics.load, the code stub should always be
called instead
* Add new test to mjsunit atomics test; check that Smi values of different
sizes are supported when possible, else fall back to HeapNumbers
These changes were needed to add another codestub:
* Bump kStubMajorKeyBits from 7 to 8
* Reduce ScriptContextFieldStub::kSlotIndexBits from 13 to 12
BUG=v8:4614
LOG=y
TBR=jarin@chromium.org,bmeurer@chromium.org,rodolph.perfetta@gmail.com,machenbach@chromium.org
Review URL: https://codereview.chromium.org/1617503003
Cr-Commit-Position: refs/heads/master@{#35427}
Review URL: https://codereview.chromium.org/1881383003
Cr-Commit-Position: refs/heads/master@{#35453}
Reason for revert:
[Sheriff] Roll was reverted. Please fix unused methods, see:
https://codereview.chromium.org/1884913002/https://build.chromium.org/p/tryserver.chromium.win/builders/win_clang/builds/5585/steps/compile%20%28with%20patch%29/logs/stdio
Original issue's description:
> [Atomics] code stubs for atomic operations
>
> * New atomic code stubs for x64, ia32, arm, arm64
> * Add convenience functions JumpIfNotValidSmiValue, JumpIfUintNotValidSmiValue
> to macro-assembler-ia32 (API based on x64 macro assembler)
> * Remove runtime implementation of Atomics.load, the code stub should always be
> called instead
> * Add new test to mjsunit atomics test; check that Smi values of different
> sizes are supported when possible, else fall back to HeapNumbers
>
> These changes were needed to add another codestub:
> * Bump kStubMajorKeyBits from 7 to 8
> * Reduce ScriptContextFieldStub::kSlotIndexBits from 13 to 12
>
> BUG=v8:4614
> LOG=y
>
> Committed: https://crrev.com/10b5febe11b318cfef130abae343183ac862e60d
> Cr-Commit-Position: refs/heads/master@{#35427}
TBR=jarin@chromium.org,bmeurer@chromium.org,rodolph.perfetta@gmail.com,binji@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4614
Review URL: https://codereview.chromium.org/1884883003
Cr-Commit-Position: refs/heads/master@{#35443}
* New atomic code stubs for x64, ia32, arm, arm64
* Add convenience functions JumpIfNotValidSmiValue, JumpIfUintNotValidSmiValue
to macro-assembler-ia32 (API based on x64 macro assembler)
* Remove runtime implementation of Atomics.load, the code stub should always be
called instead
* Add new test to mjsunit atomics test; check that Smi values of different
sizes are supported when possible, else fall back to HeapNumbers
These changes were needed to add another codestub:
* Bump kStubMajorKeyBits from 7 to 8
* Reduce ScriptContextFieldStub::kSlotIndexBits from 13 to 12
BUG=v8:4614
LOG=y
Review URL: https://codereview.chromium.org/1617503003
Cr-Commit-Position: refs/heads/master@{#35427}
Reason for revert:
Did not fail on another roll including this CL ..
Original issue's description:
> Revert of [compiler] Make feedback vector cope with flag changes. (patchset #1 id:1 of https://codereview.chromium.org/1869693003/ )
>
> Reason for revert:
> Blocks current roll: https://codereview.chromium.org/1876713002/ according to bisect: https://codereview.chromium.org/1872353002/#ps80001
>
> Original issue's description:
> > [compiler] Make feedback vector cope with flag changes.
> >
> > This fixes corner cases where the layout of feedback vectors baked into
> > the snapshot is different from the expected layout, depending on some
> > runtime flags. We make sure the feedback vector is regenereated for
> > functions that are not compiled. Flag changes of this kind are only
> > allowed when code is not serialized.
> >
> > An alternative solution would be to not serialize the feedback vector
> > for such cases in the first place. That solution however would have a
> > higher overhead, as it would required the serializer to be able to
> > recognize feedback vectors while generating a snapshot.
> >
> > R=mvstanton@chromium.org
> > TEST=mjsunit/regress/regress-crbug-600995
> > BUG=chromium:600995
> > LOG=n
> >
> > Committed: https://crrev.com/460bff5fb6af2bd79e610f89afdf6da9dba3cf0c
> > Cr-Commit-Position: refs/heads/master@{#35339}
>
> TBR=mvstanton@chromium.org,mstarzinger@chromium.org
>
> BUG=chromium:600995
> LOG=N
> NOTRY=true
>
> Committed: https://crrev.com/78049e9c4837f053575d6c71e53ae12fec99f1aa
> Cr-Commit-Position: refs/heads/master@{#35392}
TBR=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=chromium:600995
Review URL: https://codereview.chromium.org/1876973002
Cr-Commit-Position: refs/heads/master@{#35398}
Reason for revert:
Blocks current roll: https://codereview.chromium.org/1876713002/ according to bisect: https://codereview.chromium.org/1872353002/#ps80001
Original issue's description:
> [compiler] Make feedback vector cope with flag changes.
>
> This fixes corner cases where the layout of feedback vectors baked into
> the snapshot is different from the expected layout, depending on some
> runtime flags. We make sure the feedback vector is regenereated for
> functions that are not compiled. Flag changes of this kind are only
> allowed when code is not serialized.
>
> An alternative solution would be to not serialize the feedback vector
> for such cases in the first place. That solution however would have a
> higher overhead, as it would required the serializer to be able to
> recognize feedback vectors while generating a snapshot.
>
> R=mvstanton@chromium.org
> TEST=mjsunit/regress/regress-crbug-600995
> BUG=chromium:600995
> LOG=n
>
> Committed: https://crrev.com/460bff5fb6af2bd79e610f89afdf6da9dba3cf0c
> Cr-Commit-Position: refs/heads/master@{#35339}
TBR=mvstanton@chromium.org,mstarzinger@chromium.org
BUG=chromium:600995
LOG=N
NOTRY=true
Review URL: https://codereview.chromium.org/1876103002
Cr-Commit-Position: refs/heads/master@{#35392}
Function bindings are the only variables in LEGACY_CONST mode.
(https://codereview.chromium.org/1819123002/). Since these variables
can also be accessed in strict mode functions we should support
handling such variables. Assigning to a legacy constant throws
a TypeError in strict mode. Also fixes hydrogen.cc to throw a
TypeError for legacy constants.
BUG=v8:4280,chromium:599068
LOG=N
TBR=rmcilroy@chromium.org
Review URL: https://codereview.chromium.org/1845223006
Cr-Commit-Position: refs/heads/master@{#35383}
This fixes corner cases where the layout of feedback vectors baked into
the snapshot is different from the expected layout, depending on some
runtime flags. We make sure the feedback vector is regenereated for
functions that are not compiled. Flag changes of this kind are only
allowed when code is not serialized.
An alternative solution would be to not serialize the feedback vector
for such cases in the first place. That solution however would have a
higher overhead, as it would required the serializer to be able to
recognize feedback vectors while generating a snapshot.
R=mvstanton@chromium.org
TEST=mjsunit/regress/regress-crbug-600995
BUG=chromium:600995
LOG=n
Review URL: https://codereview.chromium.org/1869693003
Cr-Commit-Position: refs/heads/master@{#35339}
As originally implemented, a SingleNameBinding within a BindingPattern
was incorrectly interpreted as an assignment if an initializer was
present and that initializer was itself an AssignmentExpresion.
For example:
let x;
{ let [x = y = 1] = []; }
print(x); // expected: undefined, actual: 1
Extend the heuristic that detects the "context" of a destructuring
pattern to account for AssignmentExpressions within SingleNameBindings.
BUG=v8:4891
LOG=N
R=adamk@chromium.org
Review URL: https://codereview.chromium.org/1859423002
Cr-Commit-Position: refs/heads/master@{#35334}
Pushing undefined onto a FAST_DOUBLE_ARRAY does not enforce the right representation checks.
BUG=chromuim:599089
LOG=n
Review URL: https://codereview.chromium.org/1868973002
Cr-Commit-Position: refs/heads/master@{#35332}
We have to preserve control flow so that the liveness analysis is less
confused. This CL fixes loops to preserve teh original control flow.
BUG=chromium:599710
LOG=n
Review URL: https://codereview.chromium.org/1863123002
Cr-Commit-Position: refs/heads/master@{#35318}
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}
The parser eagerly rewrites destructuring assignments occuring
in formal parameter initializers, because not doing so would
cause the BindingPattern rewriting to be confused and do the
wrong thing.
This change prevents this rewriting from descending into the
bodies of lazily parsed functions.
In general, it's a mistake to descend into the bodies of function
literals anyways, since they are rewritten separately on their
own time, so there is no distinction made between lazily
"throw away" eagerly parsed functions in the temporary parser
arena, or "real" eagerly parsed functions that will be compiled.
BUG=chromium:594084, v8:811
LOG=N
R=adamk@chromium.org, littledan@chromium.org
Review URL: https://codereview.chromium.org/1864553002
Cr-Commit-Position: refs/heads/master@{#35277}
Previously, CreateDataProperty would fail a DCHECK when used to create
an integer indexed property on a TypedArray. This patch makes it throw
a TypeError instead. The issue came up when Array.prototype.concat
was repaired to use CreateDataProperty rather than SetElement; concat
can be tricked into making a new TypedArray if it is given an Array
whose prototype is a TypedArray. This patch prevents the issue.
R=adamk
LOG=Y
BUG=chromium:596394
Review URL: https://codereview.chromium.org/1821723004
Cr-Commit-Position: refs/heads/master@{#35271}
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}
If we use ScopeIterator inside a debug-evaluate call, we may iterate
over a debug-evaluate context that we created for the debug-evaluate
call. This may trigger assertions.
The solution is to have the ScopeIterator hide debug-evaluate contexts
by unwrapping it if it comes across any.
R=cbruni@chromium.org
BUG=chromium:599662
LOG=N
Review URL: https://codereview.chromium.org/1859033002
Cr-Commit-Position: refs/heads/master@{#35258}
There were a couple of issues with it:
- interpreter is not supported
- the source position was just accidentally correct for full-codegen
- the eval origin could have been cached
Also fixes a few other places to use AbstractCode.
R=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/1854713002
Cr-Commit-Position: refs/heads/master@{#35257}
When seeing a rest pattern, we used to get the remaining elements from the
iterator by calling %concat_iterable_to_array on it. This was wrong because it
caused an observable [[Get]] for @@iterator (which the iterator may not even
provide).
This CL gets rid of the call to %concat_iterable_to_array and does the iteration
manually in a simple while-loop. It also gets rid of %concat_iterable_to_array
itself because there aren't any other uses of it.
BUG=v8:4759
LOG=n
R=adamk@chromium.org
Review URL: https://codereview.chromium.org/1852703002
Cr-Commit-Position: refs/heads/master@{#35251}
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}
- RegExp.prototype.toString() doesn't have any special handling of
RegExp instances and simply calls the source and flags getters
- Use the original values of global and sticky, rather than based
on the current flag getters, as specified in
https://github.com/tc39/ecma262/pull/494R=yangguo@chromium.org,adamk
LOG=Y
BUG=v8:4602
Review URL: https://codereview.chromium.org/1846303002
Cr-Commit-Position: refs/heads/master@{#35225}
This allows us to remove the troublesome %_MathClz32 intrinsic and also
allows us to utilize the functionality that is already available in
TurboFan. Also introduce a proper NumberClz32 operator so we don't need
to introduce a machine operator at the JS level.
R=epertoso@chromium.org
Review URL: https://codereview.chromium.org/1852553003
Cr-Commit-Position: refs/heads/master@{#35208}
Handles bytecodeArray Objects when verifying the heap and also when
collecting code statistics. The changes include:
1. BytecodeArrays could be a part of the large object space. When
verifying the large object space we should also allow BytecodeArray
objects.
2. Adds support for BytecodeArrays when collecting code statistics.
BUG=v8:4280,chromium:599001
LOG=N
Review URL: https://codereview.chromium.org/1850443006
Cr-Commit-Position: refs/heads/master@{#35202}
Reason for revert:
breaks some chromium browser_tests: https://codereview.chromium.org/1848233002/
Original issue's description:
> Ship --harmony-regexp-exec
>
> There are still spec compliance fixes to be made, but this patch
> turns the flag to shipping to make sure we get more canary coverage
> and performance data from the bots.
>
> BUG=v8:4602
> LOG=y
>
> Committed: https://crrev.com/84492bb66b340f4e0df36758e98fddbb10b5d1dc
> Cr-Commit-Position: refs/heads/master@{#35181}
TBR=littledan@chromium.org,adamk@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4602
Review URL: https://codereview.chromium.org/1852673003
Cr-Commit-Position: refs/heads/master@{#35198}
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}
There are still spec compliance fixes to be made, but this patch
turns the flag to shipping to make sure we get more canary coverage
and performance data from the bots.
BUG=v8:4602
LOG=y
Review URL: https://codereview.chromium.org/1847103002
Cr-Commit-Position: refs/heads/master@{#35181}
Reason for revert:
TC39 decided that this compatibility fix should be standardized.
Original issue's description:
> Remove RegExp.prototype.source getter compat workaround
>
> The getter RegExp.prototype.source is specified in ES2015 to throw when
> called on a non-RegExp instance, such as RegExp.prototype. We had previously
> put in a compatibility workaround for all RegExp getters to make them
> throw on access specifically with RegExp.prototype as the receiver; however,
> we only have evidence that this is needed for properties other than source.
> This patch removes the compatibility workaround for get RegExp.prototype.source
> and gives it semantics precisely as per the ES2015 specification.
>
> R=adamk
> BUG=chromium:581577,v8:4827
> LOG=Y
>
> Committed: https://crrev.com/80803aa89e31839b8f73959776fa7e1923c6b461
> Cr-Commit-Position: refs/heads/master@{#35086}
R=adamk@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=chromium:581577,v8:4827
LOG=Y
Review URL: https://codereview.chromium.org/1847783003
Cr-Commit-Position: refs/heads/master@{#35180}
In the earlier implementation of GenerateDoubleToObject the context
is loaded from the parent's frame. rsi is clobbered because it is used
to store kHoleNan constnat. It is not always safe to peek at
the parents frame. Bytecode handlers have TypedFrame and the type of
frame is stored at FP + 1. GenerateDoubleToObject expects context
to be store at that place. In the current implementation rsi is pushed
onto the stack and is popped when exiting this function.
BUG=v8:4280,chromium:597565
LOG=N
Review URL: https://codereview.chromium.org/1848473002
Cr-Commit-Position: refs/heads/master@{#35163}
Migrate Math.ceil, Math.round and Math.trunc to TurboFan code stubs,
similar to what we did with Math.floor, and make these builtins properly
optimizable in TurboFan via appropriate simplified operators NumberCeil,
NumberRound and NumberTrunc, which are intended to be reusable for
ToInteger and ToLength optimizations that will be done in a followup CL.
Also allows us to kill the funky %RoundNumber runtime function, which
was quite heavy.
Improve test coverage for Math.ceil and Math.trunc a lot, especially
making sure that we also properly trigger the TurboFan builtin reducer
case.
R=jarin@chromium.org
BUG=v8:4059
LOG=n
Review URL: https://codereview.chromium.org/1841993002
Cr-Commit-Position: refs/heads/master@{#35135}
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}
This fixes another bug in Array.prototype.sort (when the array is not a
JSArray and there is a proxy on the prototype chain).
R=cbruni@chromium.org
BUG=chromium:596866
LOG=n
Review URL: https://codereview.chromium.org/1842563004
Cr-Commit-Position: refs/heads/master@{#35101}
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}
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}
The getter RegExp.prototype.source is specified in ES2015 to throw when
called on a non-RegExp instance, such as RegExp.prototype. We had previously
put in a compatibility workaround for all RegExp getters to make them
throw on access specifically with RegExp.prototype as the receiver; however,
we only have evidence that this is needed for properties other than source.
This patch removes the compatibility workaround for get RegExp.prototype.source
and gives it semantics precisely as per the ES2015 specification.
R=adamk
BUG=chromium:581577,v8:4827
LOG=Y
Review URL: https://codereview.chromium.org/1837843002
Cr-Commit-Position: refs/heads/master@{#35086}
Previously, they would check for Symbol.match/Symbol.search, and then
do another check for Symbol.match in the RegExp constructor. This patch
avoids the second one by skipping the RegExp constructor, as the spec does.
Review URL: https://codereview.chromium.org/1840723002
Cr-Commit-Position: refs/heads/master@{#35085}
Add support for optimizing objects with elements, which do not invoke JS and
cannot change the shape of the Object.
BUG=v8:4663
LOG=N
Review URL: https://codereview.chromium.org/1767113004
Cr-Commit-Position: refs/heads/master@{#35081}
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}
This patch implements ES2015 RegExp subclassing semantics, namely the
hardest part where RegExp.prototype.exec and certain flag getters can
be overridden in order to provide different behavior. This change is
hidden behind a new flag, --harmony-regexp-exec. The flag guards the
behavior by installing entirely different implementations of the
methods which follow the new semantics.
Preliminary performance tests show a 3-4x regression in the Octane
RegExp benchmark. The new code doesn't call out into several fast
paths that the old code supported, so this is expected.
The patch is tested mostly by test262, where most RegExp tests are fixed,
with the exception of deliberate spec violations for web compatibility,
and for the 'sticky' flag, which is not dynamically read by this patch
in all cases but rather statically compiled into the RegExp. The latter
will require a follow-on patch to implement. A small additional set of
tests verifies one particular case, mostly to check whether the flag
mechanism works.
R=adamk,yangguo@chromium.org
LOG=Y
BUG=v8:4602
Review URL: https://codereview.chromium.org/1596483005
Cr-Commit-Position: refs/heads/master@{#35068}
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}
With the recent spec change removing the [[Enumerate]] internal method, we now
have to walk the complete prototype chain. This implies that we call the
[[GetPrototypeOf]] trap on proxies.
As a secondary change we now trigger the [[GetOwnProperty]] trap for the for-in
filter step to see whether the properties are still enumerable. Before we did this
in the key-accumulation phase. This way we slightly reduce the number of traps
invoked. Whilst this is not ideal, it comes closer to the Spec's example
implementation.
BUG=v8:1543, v8:4768
LOG=n
Review URL: https://codereview.chromium.org/1748923003
Cr-Commit-Position: refs/heads/master@{#35017}
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}
This CL adds support for builtins with JavaScript linkage written using
the TurboFan CodeStubAssembler, but with a JSCall descriptor (which was
already supported thanks to a previous patch by Ben Smith). As a first
example, we convert the Math.sqrt builtin and thereby get rid of the
%_MathSqrt intrinsic, which causes trouble for the representation
selection pass in the JavaScript pipeline.
R=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/1824993002
Cr-Commit-Position: refs/heads/master@{#34989}
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}
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}
We don't want them to disappear from the stack traces.
BUG=v8:4698
LOG=N
Review URL: https://codereview.chromium.org/1818063002
Cr-Commit-Position: refs/heads/master@{#34957}
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}
This rebaselines all our internal tests for error messages thrown by the
implementation of 'instanceof' to the new ES6 semantics. It also applies
a minor rephrasing to the messages in question.
R=rossberg@chromium.org
BUG=v8:4447
LOG=n
Review URL: https://codereview.chromium.org/1822663002
Cr-Commit-Position: refs/heads/master@{#34940}
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}
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}
Reason for revert:
This patch actually seemed to cause a further GameBoy regression! Reverting it seems to address the regression.
Original issue's description:
> Restore per-TypedArray-class length accessors as a perf workaround
>
> This patch is a workaround to the performance regression caused by
> implementing the ES2015 TypedArray prototype chain: Include a
> per-TypedArray-subclass length getter so that the superclass getter does
> not become polymorphic. The patch appears to fix a regression in the
> Gameboy Octane benchmark.
>
> BUG=chromium:579905
> R=adamk
> LOG=Y
>
> Committed: https://crrev.com/03ce7711e474a0ef74f723b30ae1527c89dec010
> Cr-Commit-Position: refs/heads/master@{#33501}
R=adamk@chromium.org
BUG=chromium:579905,chromium:593634
LOG=Y
Review URL: https://codereview.chromium.org/1812143004
Cr-Commit-Position: refs/heads/master@{#34906}
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}
The way desugared instanceof called OrdinaryHasInstance if the lookup of
@@hasInstance failed was incorrect.
BUG=v8:4774
LOG=N
Review URL: https://codereview.chromium.org/1812793002
Cr-Commit-Position: refs/heads/master@{#34855}
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}
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}
We need to pop the context to correct level on return as well. This was incorrectly
removed in this cl: https://codereview.chromium.org/1768123002/. For example
when we have a try-catch-finally block and catch does a return, the return
does not happen immediately. It should execute finally block before it
returns. Return statement should pop the context to the correct level as
expected by finally block.
BUG=594369,v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1796893002
Cr-Commit-Position: refs/heads/master@{#34822}
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}
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}
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}
src/js/regexp.js was one of the few files that was left in sloppy
mode. The ES2017 draft specification requires that writes to
lastIndex throw when the property is non-writable, and test262
tests enforce this behavior. This patch puts that file in strict
mode.
BUG=v8:4504
R=yangguo@chromium.org
LOG=Y
Review URL: https://codereview.chromium.org/1776883005
Cr-Commit-Position: refs/heads/master@{#34801}
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}
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}
ES2015 Object.prototype.toString semantics were enabled in version 4.9,
which has been in stable Chrome for nearly two weeks at this point.
R=littledan@chromium.org
Review URL: https://codereview.chromium.org/1784033002
Cr-Commit-Position: refs/heads/master@{#34732}
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}
After histrogram timer added time recaling functionality,
some events, e.g. parse, histogram timer generates event log ending with 'MicroSeconds'.
Since ProfViz can't recorgnize it, this patch cuts off 'MicroSeconds' postfix.
R=vogelheim@chromium.org, yangguo@chromium.org
BUG=chromium:
LOG=N
Review URL: https://codereview.chromium.org/1771293002
Cr-Commit-Position: refs/heads/master@{#34710}
- Make separate iterator functions for TypedArrays which do a type check
(and in the future should check for detached TypedArrays)
- Share the toString method with Arrays
BUG=v8:4785
R=adamk
LOG=Y
Review URL: https://codereview.chromium.org/1780113002
Cr-Commit-Position: refs/heads/master@{#34698}
This check is guaranteed by the Promise spec and tested by test262
tests. It only has to run for subclasses. This patch adds the check
to the Promise code.
BUG=v8:4633
R=adamk
LOG=Y
Review URL: https://codereview.chromium.org/1780823003
Cr-Commit-Position: refs/heads/master@{#34693}
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}
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}
We must close the iterator whenever the destructuring didn't exhaust it, unless an iterator operation (eg. next) threw. We do this by wrapping the iterator use in a try-catch-finally similar to the desugaring of for-of.
This is behind --harmony-iterator-close.
R=adamk@chromium.org
BUG=v8:3566
LOG=Y
Review URL: https://codereview.chromium.org/1772793002
Cr-Commit-Position: refs/heads/master@{#34654}
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}
