Where the arguments have already been inlined, we can replace these
calls with a direct call. We have to make sure that the iteration over
the arguments is not observable.
Also factor out the large chunk of logic shared with
ReduceJSConstructWithSpread.
BUG=v8:5932
Change-Id: I6c4fac670028fbd8ca82c4474d4392231573bc49
Reviewed-on: https://chromium-review.googlesource.com/439329
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43039}
It used to require >1GB of memory which leads to flaky test failures on
machines with less memory when executing multiple variants in parallel
R=cbruni@chromium.org,ulan@chromium.org
BUG=v8:5706
Change-Id: Id8c6f49cbfa51f2d443991c1493f225810efb18f
Reviewed-on: https://chromium-review.googlesource.com/439310
Commit-Queue: Camillo Bruni <cbruni@google.com>
Commit-Queue: Jochen Eisinger <jochen@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43038}
The testb instruction requires the REX prefix when either of its
operands uses a register with the high bit set. The existing code only
considered the register operand. In the test case the REX prefix was not
emitted because the testb instruction had the register operand RAX which
does not have the high bit set. The REX prefix was necessary though
because the memory operand used R8, which has the high bit set.
R=bmeurer@chromium.org
BUG=chromium:688876
Change-Id: Ib214bebbe75965664f2aea530e29afa95a54f44f
Reviewed-on: https://chromium-review.googlesource.com/439145
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43030}
Reason for revert:
False alarm, bot hiccup
Original issue's description:
> Revert of [parsing] Fix maybe-assigned for loop variables. (patchset #3 id:40001 of https://codereview.chromium.org/2673403003/ )
>
> Reason for revert:
> Speculative revert because of https://codereview.chromium.org/2679163002/.
>
> Original issue's description:
> > [parsing] Fix maybe-assigned for loop variables.
> >
> > Due to hoisting, the value of a 'var'-declared variable may actually change even
> > if the code contains only the "initial" assignment, namely when that assignment
> > occurs inside a loop. For example:
> >
> > let i = 10;
> > do { var x = i } while (i--):
> >
> > As a simple and very conservative approximation of this, we explicitly mark
> > as maybe-assigned any non-lexical variable whose "declaration" does not
> > syntactically occur in the function scope. (In the example above, it
> > occurs in a block scope.)
> >
> > BUG=v8:5636
> >
> > Review-Url: https://codereview.chromium.org/2673403003
> > Cr-Commit-Position: refs/heads/master@{#42989}
> > Committed: a33fcd663b
>
> TBR=marja@chromium.org,adamk@chromium.org,neis@chromium.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=v8:5636
>
> Review-Url: https://codereview.chromium.org/2679263002
> Cr-Commit-Position: refs/heads/master@{#43010}
> Committed: f3ae5ccf57TBR=marja@chromium.org,adamk@chromium.org,neis@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5636
Review-Url: https://codereview.chromium.org/2686663002
Cr-Commit-Position: refs/heads/master@{#43013}
Reason for revert:
False alarm, bot hiccup
Original issue's description:
> Revert of Thread maybe-assigned through the bytecodes. (patchset #5 id:80001 of https://codereview.chromium.org/2655733003/ )
>
> Reason for revert:
> needed for properly reverting f3ae5ccf57
>
> Original issue's description:
> > Thread maybe-assigned through the bytecodes.
> >
> > This introduces LoadImmutableContextSlot and LoadImmutableCurrentContextSlot
> > bytecodes, which are emitted when reading from never-assigned context slot.
> >
> > There is a subtlety here: the slot are not immutable, the meaning is
> > actually undefined-or-hole-or-immutable.
> >
> > Review-Url: https://codereview.chromium.org/2655733003
> > Cr-Commit-Position: refs/heads/master@{#43000}
> > Committed: 17c2dd3886
>
> TBR=rmcilroy@chromium.org,bmeurer@chromium.org,neis@chromium.org,jarin@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/2680923003
> Cr-Commit-Position: refs/heads/master@{#43011}
> Committed: ece4e54a31TBR=rmcilroy@chromium.org,bmeurer@chromium.org,neis@chromium.org,jarin@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/2679953003
Cr-Commit-Position: refs/heads/master@{#43012}
Reason for revert:
needed for properly reverting f3ae5ccf57
Original issue's description:
> Thread maybe-assigned through the bytecodes.
>
> This introduces LoadImmutableContextSlot and LoadImmutableCurrentContextSlot
> bytecodes, which are emitted when reading from never-assigned context slot.
>
> There is a subtlety here: the slot are not immutable, the meaning is
> actually undefined-or-hole-or-immutable.
>
> Review-Url: https://codereview.chromium.org/2655733003
> Cr-Commit-Position: refs/heads/master@{#43000}
> Committed: 17c2dd3886TBR=rmcilroy@chromium.org,bmeurer@chromium.org,neis@chromium.org,jarin@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/2680923003
Cr-Commit-Position: refs/heads/master@{#43011}
Reason for revert:
Speculative revert because of https://codereview.chromium.org/2679163002/.
Original issue's description:
> [parsing] Fix maybe-assigned for loop variables.
>
> Due to hoisting, the value of a 'var'-declared variable may actually change even
> if the code contains only the "initial" assignment, namely when that assignment
> occurs inside a loop. For example:
>
> let i = 10;
> do { var x = i } while (i--):
>
> As a simple and very conservative approximation of this, we explicitly mark
> as maybe-assigned any non-lexical variable whose "declaration" does not
> syntactically occur in the function scope. (In the example above, it
> occurs in a block scope.)
>
> BUG=v8:5636
>
> Review-Url: https://codereview.chromium.org/2673403003
> Cr-Commit-Position: refs/heads/master@{#42989}
> Committed: a33fcd663bTBR=marja@chromium.org,adamk@chromium.org,neis@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5636
Review-Url: https://codereview.chromium.org/2679263002
Cr-Commit-Position: refs/heads/master@{#43010}
This introduces LoadImmutableContextSlot and LoadImmutableCurrentContextSlot
bytecodes, which are emitted when reading from never-assigned context slot.
There is a subtlety here: the slot are not immutable, the meaning is
actually undefined-or-hole-or-immutable.
Review-Url: https://codereview.chromium.org/2655733003
Cr-Commit-Position: refs/heads/master@{#43000}
... and TypeFeedbackMetadata to FeedbackMetadata.
BUG=
Change-Id: I2556d1c2a8f37b8cf3d532cc98d973b6dc7e9e6c
Reviewed-on: https://chromium-review.googlesource.com/439244
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#42999}
Due to hoisting, the value of a 'var'-declared variable may actually change even
if the code contains only the "initial" assignment, namely when that assignment
occurs inside a loop. For example:
let i = 10;
do { var x = i } while (i--):
As a simple and very conservative approximation of this, we explicitly mark
as maybe-assigned any non-lexical variable whose "declaration" does not
syntactically occur in the function scope. (In the example above, it
occurs in a block scope.)
BUG=v8:5636
Review-Url: https://codereview.chromium.org/2673403003
Cr-Commit-Position: refs/heads/master@{#42989}
For x64, ia32 and x87 we would pop the return address before the stack
overflow check. This meant the stack couldn't be unwound properly if
it was going to overflow. This CL moves the pop of the return address
to after the stack overflow check.
Also adds a regression test to check that a RangeError is thrown.
BUG=689016
Review-Url: https://codereview.chromium.org/2681643004
Cr-Commit-Position: refs/heads/master@{#42984}
This correctly marks the {JSCreate} operator as potentially throwing,
since it might trigger a property access of the 'prototype' property
during instantiation. This is observable, can throw (not kNoThrow),
might have side-effects (not kNoWrite), or even trigger a lazy deopt
event (not kNoDeopt). The inlining logic has been adapted to wire up
control projections accordingly.
Note that this does not yet take care of the "after" frame-state which
is associated with the {JSCreate} node introduced by the inliner. We
still might re-evaluate the property access upon lazy deoptimization.
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-5638
BUG=v8:5638
Review-Url: https://codereview.chromium.org/2671203003
Cr-Commit-Position: refs/heads/master@{#42981}
- Removes shared InnerArrayCopyWithin JS builtin from src/js/array.js
- Implements %TypedArray%.prototype.copyWithin as a C++ builtin, which
relies on std::memmove rather than accessing individual eleements.
- Fixes the case where copyWithin is invoked on a TypedArray with a
detached buffer.
- Add tests to ensure that +/-Infinity (for all 3 parameters) is handled correctly by the
algorithm
The C++ version gets through the benchmark more than 25000 times as
quickly as the JS implementation.
BUG=v8:5925, v8:5929, v8:4648
R=cbruni@chromium.org, adamk@chromium.org, littledan@chromium.org
Review-Url: https://codereview.chromium.org/2671233002
Cr-Commit-Position: refs/heads/master@{#42975}
TypeFeedbackVectors are strongly rooted by a closure. However, in modern
JavaScript closures are created and abandoned more freely. An important
closure may not be present in the root-set at time of garbage collection,
even though we've cached optimized code and use it regularly. For
example, consider leaf functions in an event dispatching system. They may
well be "hot," but tragically non-present when we collect the heap.
Until now, we've relied on a weak root to cache the feedback vector in
this case. Since there is no way to signal intent or relative importance,
this weak root is as susceptible to clearing as any other weak root at
garbage collection time.
Meanwhile, the feedback vector has become more important. All of our
ICs store their data there. Literal and regex boilerplates are stored there.
If we lose the vector, then we not only lose optimized code built from
it, we also lose the very feedback which allowed us to create that optimized
code. Therefore it's vital to express that dependency through the root
set.
This CL does this by creating a strong link to a feedback
vector at the instantiation site of the function closure.
This instantiation site is in the code and feedback vector
of the outer closure.
BUG=v8:5456
Review-Url: https://codereview.chromium.org/2674593003
Cr-Commit-Position: refs/heads/master@{#42953}
TailCallRuntime currently does not seem to handle adaptor frames
correctly.
BUG=chromium:688690
Review-Url: https://codereview.chromium.org/2675133003
Cr-Commit-Position: refs/heads/master@{#42950}
Also if the count is not specified, it should wake all waiters.
BUG=v8:4777
Review-Url: https://codereview.chromium.org/2659083004
Cr-Commit-Position: refs/heads/master@{#42871}
Using .caller, one can get access to the internal function that invokes the
handler passed to Promise.prototype.then. This internal function is a TF
builtin that was set up as non-native and without an argument adaptor. As a
consequence of this, when accessing .arguments on it, the frame-walking logic in
the .arguments accessor thinks the number of arguments is -1 and we try to
allocate an array of size -1.
This CL marks the builtin function as native (making its .arguments be null),
along with a few others that may have been incorrect in the same way.
BUG=chromium:682349
Review-Url: https://codereview.chromium.org/2672453002
Cr-Commit-Position: refs/heads/master@{#42855}
The function being tested is forced to go through Turbofan anyway (since it references a module variable).
Adding --turbo explicitly just to make a check happy.
BUG=
Review-Url: https://codereview.chromium.org/2664393003
Cr-Commit-Position: refs/heads/master@{#42844}
Also updated some tests due to the change. The general pattern is when a
trailing comma is expected to cause a SyntaxError, an additional comma was
added.
BUG=v8:5051
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel
Review-Url: https://codereview.chromium.org/2638513002
Cr-Commit-Position: refs/heads/master@{#42826}
The KeyedStoreMode that we get out of the FeedbackNexus doesn't
necessarily need to apply when we have "static knowledge" about
the receiver, i.e. when the receiver is a known JSTypedArray, but
the KEYED_STORE_IC has seen only JSArray instances so far. The
DCHECK was too restrictive in this case, since we can just ignore
the KEYED_STORE_IC mode (like we ignore the maps).
BUG=chromium:685050
R=ishell@chromium.org
Review-Url: https://codereview.chromium.org/2668643002
Cr-Commit-Position: refs/heads/master@{#42810}
We were missing a case for Tagged->TaggedSigned conversions when the
input type is known to be Type::SignedSmall.
BUG=chromium:687029
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2666863002
Cr-Commit-Position: refs/heads/master@{#42809}
We cannot eliminate unused CheckFloat64Hole nodes, since loading from a
holey array can have side-effects, i.e. triggering getters in the
prototype chain.
R=mvstanton@chromium.org
BUG=chromium:686737
Review-Url: https://codereview.chromium.org/2665123002
Cr-Commit-Position: refs/heads/master@{#42806}
When WebAssembly.Table initial size is greater than the declared initial size, table size references should be updated on instantiate for functions to be called at indices greater than the declared initial size.
R=bradnelson@chromium.org, titzer@chromium.org
Review-Url: https://codereview.chromium.org/2661773002
Cr-Commit-Position: refs/heads/master@{#42781}
