The stack check at the beginning of each function maps to the wasm byte
offset 0. For asm.js functions, this byte offset is mapped further to an
asm.js source position. For most functions, we explicitly add an entry
to this side table for offset 0. This was missing for the start
function.
R=ahaas@chromium.org
BUG=v8:4203,chromium:703568
Change-Id: I05bc4a8cfa666864bb7a0b23f75186abe0be9bee
Reviewed-on: https://chromium-review.googlesource.com/458437
Commit-Queue: Brad Nelson <bradnelson@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44037}
This fixes a corner case where the "instance prototype" diverges from
the "non-instance prototype" that we store on the initial map of a
constructor function.
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-crbug-703610
BUG=chromium:703610
Change-Id: I30a19ae621e10b512215ffb191ce00d030941440
Reviewed-on: https://chromium-review.googlesource.com/458396
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44008}
This fixes a bug where an exported function is being specialized, but
the callsite inside the JS_TO_WASM function was patched to call an
interpreter entry instead. We would not identify the call site as the
one to be patched during specialization, and would thus fail a DCHECK.
R=ahaas@chromium.org
BUG=v8:5822, chromium:702839
Change-Id: I148d98333051c399a4cb11bd9620b396f4eb261d
Reviewed-on: https://chromium-review.googlesource.com/456282
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43942}
We use LoadFromPrototype also for direct global loads. InitPrototypeChecks did not support this though, and would create a prototype chain check for objects beyond the direct global. This tries to ensure the property on the global itself doesn't exist, which is invalid.
Additionally this CL deletes duplicate code.
BUG=chromium:702798,v8:5561
Change-Id: I318a5b6cd5f7c3efdb3a003e34edd37d5d3f880b
Reviewed-on: https://chromium-review.googlesource.com/457369
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43935}
Don't ignore IfException (and IfSuccess) projections on JSForInNext
nodes during JSTypedLowering::ReduceJSForInNext, but instead rewrire
the IfException projection to the ForInFilter stub call, which can
throw exceptions in case of proxies.
R=yangguo@chromium.org
BUG=v8:6121
Review-Url: https://codereview.chromium.org/2761703002
Cr-Commit-Position: refs/heads/master@{#43925}
BUG=chromium:702793
Change-Id: Ia52823968a757f8f7fc8802deab60f570ffdb58c
Reviewed-on: https://chromium-review.googlesource.com/456280
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43920}
The fast-path for Array.prototype.indexOf first checks whether the
receiver is a fast-mode JSArray (and there are no elements in the
prototype chain in case of holey arrays), then loads the known
JSArray::length, and afterwards calls ToInteger on the fromIndex.
But this ToInteger(fromIndex) call can cause arbitrary side effects if
the fromIndex is a JSReceiver, in particular it can invalidate the
assumptions about the fast-mode of the receiver and the length. In the
worst case this leads to OOB memory access.
Quick-fix is to bailout to the runtime if the fromIndex is neither a Smi
nor undefined, which represents the common cases.
R=jarin@chromium.org
BUG=chromium:702058
Review-Url: https://codereview.chromium.org/2756663002
Cr-Commit-Position: refs/heads/master@{#43843}
Removes the --ignition-staging flag since it is no longer used
by anything and won't be a shipping configuration. Also removes
ignition_turbo variant from testrunner, since it is now
the same as the turbofan variant.
BUG=v8:4280
Change-Id: I3b96e986879fc70b8e202fe9496334828acdd0ba
Reviewed-on: https://chromium-review.googlesource.com/452621
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43806}
This fixes a corner-case in {KeyAccumulator::CollectOwnJSProxyKeys}
where the keys returned by {JSReceiver::OwnPropertyKeys} for an array
are not internalized and hence have a diverging identity from keys
returned by the "ownKeys" trap of a proxy.
R=cbruni@chromium.org
TEST=mjsunit/regress/regress-crbug-700678
BUG=chromium:700678
Change-Id: I5efd012eade14bd45c69e4abb0aeda684baf38f0
Reviewed-on: https://chromium-review.googlesource.com/452979
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43775}
The optimization
NumberFloor(NumberDivide(lhs, rhs))
to
NumberToInt32(NumberDivide(lhs, rhs))
for potentially negative lhs is not valid, since Math.floor rounds
towards -infinity, whereas ToInt32 truncates.
BUG=chromium:699282
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2743673002
Cr-Commit-Position: refs/heads/master@{#43699}
This fixes an incorrect usage of String::Flatten in EscapeRegExpSource.
It also adds %ConstructConsString (to easily and reliably construct cons
strings in tests) and Factory::NewConsString (to enable guaranteed cons
string construction without preemptive flattening attempts).
BUG=chromium:698790
Review-Url: https://codereview.chromium.org/2736383003
Cr-Commit-Position: refs/heads/master@{#43686}
The immediate passed to cmpw can be either a signed 16-bit or an
unsigned 16-bit integer, but the DCHECK was testing for signed 16-bit
values only.
R=mstarzinger@chromium.org
BUG=v8:6063
Review-Url: https://codereview.chromium.org/2735363002
Cr-Commit-Position: refs/heads/master@{#43671}
From asm.js code we might get an empty ArrayBuffer as heap memory. In
this case, both the old memory start and the new memory start will be
nullptr. The size however has to be patched from default_size to 0.
This CL changes code specialization to be able to either patch memory
references, or patch memory sizes or both.
R=titzer@chromium.org, ahaas@chromium.org
BUG=chromium:698587
Change-Id: I4d9d811d75cb83842f23df317e8e7fc02aeb5146
Reviewed-on: https://chromium-review.googlesource.com/450257
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43613}
This involved adding a count_ member to SloppyBlockFunctionMap, so
to avoid making DeclarationScope larger, this patch makes the
creation of the map lazy, thus reducing the size of DeclarationScope
by several words in the process.
BUG=chromium:688567
Change-Id: If9a9eb2ccc01690fe10edadb3aa9625454ff4a19
Reviewed-on: https://chromium-review.googlesource.com/448701
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43558}
String::SlowFlatten assumed that ConsStrings with empty first parts have
flattened strings as their second part. TurboFan, however, can create
ConsStrings with empty first parts and arbitrary second parts. With
this CL we call String::Flatten on the second part of a ConsString if
the first part is empty, but only when String::Flatten would not call
String::SlowFlatten.
R=jkummerow@chromium.org
BUG=chromium:696651
Change-Id: I9acb681de1be695e1ec2f6f6d28b9e4dc4344e98
Reviewed-on: https://chromium-review.googlesource.com/448457
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43513}
The maybe-assigned flag of the catch variable was not preserved.
BUG=v8:5636,chromium:696332
Change-Id: I9c55e1b1312bdebc53bc45bc3ca1c982bdbe9846
Reviewed-on: https://chromium-review.googlesource.com/447680
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43506}
Previously, we over-approximated Scope::scope_calls_eval_ in
arrow functions: if either the outer scope or the arrow function
parameters had a direct eval call, we marked both scopes as calling
eval. This over-approximation kept getting us into trouble, though,
especially when eager or lazy parsing would disagree about the
"calls eval" bit.
This patch instead tracks eval calls accurately, using a boolean on
Scope::Snapshot that is reset as appropriately depending on whether
a particular AssignmentExpression turned out to be an arrow parameter
list or not.
BUG=chromium:691687
Change-Id: I527dc59b4d32a2797805ff26dc9f70b1311377b2
Reviewed-on: https://chromium-review.googlesource.com/446094
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43499}
The above intrinsic by now has to perform a check whether the prototype
of a derived constructor is actually a constructor function itself. This
is done as part of the {JSGetConstructorCall} operator. The intrinsic
should just reduce down to the operator to maintain correct semantics.
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-crbug-696622
BUG=chromium:696622
Change-Id: Ia19c188f17ad16b12248db1f01a01b8d7258499b
Reviewed-on: https://chromium-review.googlesource.com/447716
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43479}
When an instance of a constructor goes dictionary mode, this changes the initial map
of that constructor to also be in dictionary mode. This avoids spurious hidden class
creation, that also results in IC misses.
BUG=
Change-Id: I0e70f822ac345d0224f2092ec473621a603d4cc5
Reviewed-on: https://chromium-review.googlesource.com/446361
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43452}
This fixes a corner-case where the call reduction of the aforementioned
getter did not simulate the {ToObject} conversion of the receiver value
as required by the spec. This caused the wrong prototype to be constant
promoted (i.e. {null} instead of wrapper object prototype).
R=jarin@chromium.org
TEST=mjsunit/regress/regress-crbug-694709
BUG=chromium:694709
Change-Id: Idf3a37071949d9ddaf5ef43974570c06fd31c0c9
Reviewed-on: https://chromium-review.googlesource.com/445818
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43376}
This fixes a missing name check for keyed property loads targeting the
global object where the feedback was warmed up with a single name. This
affects {JSLoadProperty} nodes only, syntactic global property loads via
the {JSLoadGlobal} operator are not affected.
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-crbug-694416
BUG=chromium:694416
Change-Id: I54aa3f27eaa72630539f02602ec7642b04835b27
Reviewed-on: https://chromium-review.googlesource.com/445224
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43344}
info.This returns a Local<Object>, which results in a call to
Utils::OpenHandle<JSReceiver>. Casting to a Local<Value> first uses the
correct OpenHandle<Object> overload.
BUG=chromium:693500
Review-Url: https://codereview.chromium.org/2706833002
Cr-Commit-Position: refs/heads/master@{#43314}
The bytecode generator did not necessarily know for which scope, and
thus language mode, it was generating code, because it only tracked
scopes that have a context. This led to wrong behavior in some
examples involving class expressions (which are always in strict
mode).
With this CL, the bytecode generator explicitly tracks the current
scope, independent of whether it has a context.
BUG=v8:5927
Change-Id: Ifa6b3ee5e13e07b63d00e74c7f557a328633c88b
Reviewed-on: https://chromium-review.googlesource.com/444785
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43300}
Currently, typeof o, where o is an undetectable
callable object (such as document.all), returns 'function' if
optimised. It should, however, return 'undefined'.
This CL excludes undetectable objects from the optimization
resulting in type 'function' and renames the related code to
reflect that.
BUG=v8:5972
R=bmeurer@chromium.org
Review-Url: https://codereview.chromium.org/2697063002
Cr-Commit-Position: refs/heads/master@{#43298}
One optimization in the machine-operator-reducer did not consider that
that word32 shift left instructions only consider the last 5 bits of
the shift input.
The issue only occurs for WebAssembly because in JavaScript we always
add a "& 0xf" on the shift value to the TurboFan graph.
For additional background: The JavaScript and WebAssembly spec both
say that only the last 5 bits of the shift value are used in the
word32-shift-left operation. This means that an "x << 0x29", in the
code is actually executed as "x << 0x09". Therefore the changes in
this CL are okay because they mask the last 5 bit of the shift value.
BUG=chromium:689450
Change-Id: Id92f298ed6d7f1714b109b3f4fbcecd5ac6d30f7
Reviewed-on: https://chromium-review.googlesource.com/439312
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43245}
@@replace has a pretty complex implementation, taking different paths
for various situations (e.g.: global/nonglobal regexp, functional/string
replace argument, etc.). Each of these paths must implement similar
logic for calling into the RegExpBuiltinExec spec operation, and many
paths get this subtly wrong.
This CL fixes a couple of issues related to the way @@replace handles lastIndex:
* All paths now respect lastIndex when calling into exec (some used to assume 0).
* lastIndex is now advanced after a successful match for sticky regexps.
* lastIndex is now only reset to 0 on failure for sticky regexps.
BUG=v8:5361
Review-Url: https://codereview.chromium.org/2685183003
Cr-Commit-Position: refs/heads/master@{#43234}
The mips64 implementation always ended up in the slowpath due to some
loads that were the wrong width, so that is also fixed here.
BUG=v8:5974
Change-Id: Ie448a1fab5b7fca87597c5a1bf75443864e30c28
Reviewed-on: https://chromium-review.googlesource.com/443247
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43222}
ParserBase::is_any_identifier currently does not recognise
Token::ESCAPED_STRICT_RESERVED_WORD as an identifier. This seems different
from what ParserBase::ParseIdentifierName does, and also prevents
"l\u0065t", unlike "let", from becoming a label.
This CL extends is_any_identifier to also accept ESCAPED_STRICT_RESERVED_WORD.
BUG=v8:5692
Review-Url: https://codereview.chromium.org/2695973003
Cr-Commit-Position: refs/heads/master@{#43204}
This adds support for deoptimizing into the JSConstructStub after the
receiver instantiation but before the actual constructor invocation.
Such a deoptimization point is needed for cases where instantiation
might be observed (e.g. when new.target is a proxy) and hence might
trigger a deopt.
We use this new deoptimization point for the "after" frame-state the
inliner attaches to {JSCreate} nodes being inserted when constructor
calls are being inlined.
R=jarin@chromium.org
TEST=mjsunit/regress/regress-5638b
BUG=v8:5638
Change-Id: I7c72c807ee8fb76d12e0e9ccab86d970ab1a0efd
Reviewed-on: https://chromium-review.googlesource.com/440125
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43149}
We cannot skip the @@hasInstance lookup in instanceof depending on a
global protector cell, as the lookup of the property is observable
via proxies or accessors. So remove the global protector and properly
implement CSA::InstanceOf via GetPropertyStub, with an appropriate
fast-path for Function.prototype[@@hasInstance] where we call the
builtin code object directly if the function matches, skipping all
the checks from the call sequence, and also avoid the redundant
ToBoolean conversion on the result.
R=yangguo@chromium.orgTBR=ulan@chromium.org
BUG=v8:5958
Review-Url: https://codereview.chromium.org/2684033012
Cr-Commit-Position: refs/heads/master@{#43137}
This fixes the case where the index passed to {HMaybeGrowElements} used
to derive the new capacity for the elements backing store does not fit
into Smi range. Such an overflow would fail the capacity check and cause
growing to be skipped. Subsequent keyed stores would potentially go out
of bounds.
R=mvstanton@chromium.org
TEST=mjsunit/regress/regress-crbug-686427
BUG=chromium:686427
Review-Url: https://codereview.chromium.org/2686263002
Cr-Commit-Position: refs/heads/master@{#43101}
Collect code coverage from the available invocation counts.
The granularity is at function level, and invocation counts may
be lost to GC.
Coverage::Collect returns a std::vector of Coverage::ScriptData.
Each ScriptData contains a script ID and a std::vector of
Coverage::RangeEntry.
Each RangeEntry consists of a end position and the invocation
count. The start position is implicit from the end position of
the previous RangeEntry, or 0 if it's the first RangeEntry.
R=jgruber@chromium.org
BUG=v8:5808
Review-Url: https://codereview.chromium.org/2689493002
Cr-Commit-Position: refs/heads/master@{#43072}
E.g.,
{ function lazy_inner(b = somevar) { let somevar; } }
If we don't produce the same scopes, PreParser thinks that the unresolved
variable inside the default parameter resolves into the variable declared inside
the function. Thus, it's not correctly recorded as a free variable.
One part is already done by https://codereview.chromium.org/2638333002 . But at
the laziness boundary, we still produced different scopes.
Unlike previously thought, this is also needed for lazy inner function
correctness, not only for "preparser scope analysis" (ie., skipping inner
functions).
BUG=v8:5938
Change-Id: I047cd43ef16478bb0f18d1f114845e7d1ab8c5f2
Reviewed-on: https://chromium-review.googlesource.com/439345
Commit-Queue: Marja Hölttä <marja@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43044}
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:
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}
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}
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}
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}
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}
The StringIndexOf operation is pure on the JS level, but the actual stub
call must be in the effect chain later so that the Scheduler doesn't
place it inside some allocation region (The %StringIndexOf runtime
function may trigger a GC for string flattening).
BUG=chromium:685580
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2657243002
Cr-Commit-Position: refs/heads/master@{#42736}
The mentioned asserts did not work properly with interpreted and turbofanned functions.
To fix this issue %GetOptimizationStatus() now returns a set of flags instead of a single value.
This CL also adds more helper functions to mjsunit, like isNeverOptimize(), isAlwaysOptimize(),
isOptimized(fun), etc.
BUG=v8:5890
Review-Url: https://codereview.chromium.org/2654733004
Cr-Original-Commit-Position: refs/heads/master@{#42703}
Committed: d1ddec7857
Review-Url: https://codereview.chromium.org/2654733004
Cr-Commit-Position: refs/heads/master@{#42731}
Previously, when restarting a frame, we would rewrite all frames
between the debugger activation and the frame to restart to squash
them, and replace the return address with that of a builtin to
leave that rewritten frame, and restart the function by calling it.
We now simply remember the frame to drop to, and upon returning
from the debugger, we check whether to drop the frame, load the
new FP, and restart the function.
R=jgruber@chromium.org, mstarzinger@chromium.org
BUG=v8:5587
Review-Url: https://codereview.chromium.org/2636913002
Cr-Commit-Position: refs/heads/master@{#42725}
This corrects the case when we need to allocate a
blocked register, but the blockage happens after a
use as an instruction input, and there's no place to
split before that.
BUG=v8:5888
Review-Url: https://codereview.chromium.org/2652153005
Cr-Original-Commit-Position: refs/heads/master@{#42706}
Committed: ca779b29a6
Review-Url: https://codereview.chromium.org/2652153005
Cr-Commit-Position: refs/heads/master@{#42710}
This CL adds --crankshaft and --no-always-opt flags to the tests that use
assertOptimized() and assertUnoptimized() respectively.
This CL also adds presubmit checks that ensure that tests have the proper
flags set.
BUG=v8:5890
Review-Url: https://codereview.chromium.org/2653753007
Cr-Commit-Position: refs/heads/master@{#42709}
Reason for revert:
Introduces new crashers, e.g.
load("test/mjsunit/wasm/wasm-constants.js");
load("test/mjsunit/wasm/wasm-module-builder.js");
(function() {
var builder = new WasmModuleBuilder();
builder.addMemory(16, 32, false);
builder.addFunction("test", kSig_i_iii)
.addBodyWithEnd([
// body:
kExprI64Const, 0x42,
kExprI64Const, 0x7a,
kExprI64Ctz,
kExprI64Mul,
kExprI64Ctz,
kExprI64Const, 0x41,
kExprI64Ctz,
kExprI64Ctz,
kExprI64Shl,
kExprI64Const, 0x41,
kExprI64Ctz,
kExprI64Ctz,
kExprI64Shl,
kExprF32SConvertI64,
kExprUnreachable,
kExprEnd, // @20
])
.exportFunc();
var module = builder.instantiate();
module.exports.test(1, 2, 3);
})();
Original issue's description:
> [turbofan] Correct regalloc blocked register behavior
>
>
> This corrects the case when we need to allocate a
> blocked register, but the blockage happens after a
> use as an instruction input, and there's no place to
> split before that.
>
> BUG=v8:5888
>
> Review-Url: https://codereview.chromium.org/2652153005
> Cr-Commit-Position: refs/heads/master@{#42706}
> Committed: ca779b29a6TBR=bmeurer@chromium.org,jarin@chromium.org,mtrofin@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5888
Review-Url: https://codereview.chromium.org/2654993007
Cr-Commit-Position: refs/heads/master@{#42707}
This corrects the case when we need to allocate a
blocked register, but the blockage happens after a
use as an instruction input, and there's no place to
split before that.
BUG=v8:5888
Review-Url: https://codereview.chromium.org/2652153005
Cr-Commit-Position: refs/heads/master@{#42706}
The mentioned asserts did not work properly with interpreted and turbofanned functions.
To fix this issue %GetOptimizationStatus() now returns a set of flags instead of a single value.
This CL also adds more helper functions to mjsunit, like isNeverOptimize(), isAlwaysOptimize(),
isOptimized(fun), etc.
BUG=v8:5890
Review-Url: https://codereview.chromium.org/2654733004
Cr-Commit-Position: refs/heads/master@{#42703}
This makes sure that static guarantees about object maps are not used
accross operations on the effect chain that might trigger a map change.
Such operations are missing the {Operator::kNoWrite} property.
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-crbug-685506
BUG=chromium:685506
Review-Url: https://codereview.chromium.org/2653273004
Cr-Commit-Position: refs/heads/master@{#42697}
This makes sure that the deoptimizer preserves the exact bit pattern of
floating-point values (both 32-bit and 64-bit) up to the point where a
potential {HeapNumber} is allocated. It in turn allows us to correctly
recognize the {hole_nan_value} when stored into a {FixedDouleArray}.
R=jarin@chromium.org
TEST=mjsunit/regress/regress-crbug-684208
BUG=chromium:684208
Review-Url: https://codereview.chromium.org/2652303002
Cr-Commit-Position: refs/heads/master@{#42679}
Enable enqueueing of eager inner function compilation onto the compiler
dispatcher. This enables these tasks to be performed in parallel to
compilation of the outer functio (only for Ignition functions).
We currently synchronize to ensure all inner function compilations
are complete before executing the outer function - future work will
allow outer function execution to happenin parallel to inner function
compilation.
BUG=v8:5203,v8:5215
Review-Url: https://codereview.chromium.org/2611313002
Cr-Commit-Position: refs/heads/master@{#42667}
We did not smi-check the spread argument here, meaning we tried to take the map
of a smi, resulting in segfaults which clusterfuzz found.
Also added tests that exercise this path.
BUG=685086
Review-Url: https://codereview.chromium.org/2655013002
Cr-Commit-Position: refs/heads/master@{#42657}
This fixes the checks of accumulator usage flags in the computation of
the interpreter register liveness during bytecode analysis. The usage
flags at hand are bit patterns as opposed to flat enum values. Use the
safe accessors instead of plain comparison.
R=jarin@chromium.org
TEST=mjsunit/regress/regress-crbug-683581
BUG=chromium:683581
Review-Url: https://codereview.chromium.org/2651653005
Cr-Commit-Position: refs/heads/master@{#42648}
Array.prototype.concat does not properly handle JSProxy species that will
modify the currently visited array.
BUG=682194
Review-Url: https://codereview.chromium.org/2655623004
Cr-Commit-Position: refs/heads/master@{#42640}
This makes sure 32-bit constants that are used as {MachineType::Uint32}
by the deoptimization translation are also interpreted as such when the
literals are collected.
R=jarin@chromium.org
TEST=mjsunit/regress/regress-crbug-681983
BUG=chromium:681983
Review-Url: https://codereview.chromium.org/2646463002
Cr-Commit-Position: refs/heads/master@{#42493}
The IA32AddPair and IA32SubPair instructions were using an input register as a
temporary value, which led to registers sometimes being clobbered when they
shouldn't have been. This led to problems, for example, in calling printf to
format doubles:
printf("%f", 1.2345) => 0.61725 (on x86)
BUG= https://bugs.chromium.org/p/v8/issues/detail?id=5800
Review-Url: https://codereview.chromium.org/2637583002
Cr-Commit-Position: refs/heads/master@{#42486}
This also introduces exhaustive switch-cases for instance types.
BUG=chromium:681383
Review-Url: https://codereview.chromium.org/2646433002
Cr-Commit-Position: refs/heads/master@{#42447}
Non-capturing groups so far did not have any effect, so we elided
them in the regexp parser. However, they do affect how lookarounds
are parsed: in unicode mode, lookarounds are not quantifiable. They
are however if wrapped in a group.
BUG=v8:5845
Review-Url: https://codereview.chromium.org/2636883002
Cr-Commit-Position: refs/heads/master@{#42436}
