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}
