First step towards replacing PropertyType with two enums: {DATA,ACCESSOR} x {CONST,WRITABLE}.
Review URL: https://codereview.chromium.org/733253004
Cr-Commit-Position: refs/heads/master@{#25417}
This fixes following exception in Sky on attempt to set a breakpoint
"Unhandled: Uncaught ReferenceError: break_point is not defined"
I think this happens in Sky but not in Chrome because Sky scripts are executed in strict mode.
BUG=None
LOG=N
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/741683002
Cr-Commit-Position: refs/heads/master@{#25415}
port 47f55baeaf (r25397)
original commit message:
Re-land r25392 Use a stub in crankshaft for grow store arrays.
Code was vulnerable to different evaluation order in Clang.
BUG=
Review URL: https://codereview.chromium.org/739823002
Cr-Commit-Position: refs/heads/master@{#25414}
According to ES5 9.5 and 9.6, NaN, -inf, +inf, -0 and 0 all truncate to
zero for both ToInt32 and ToUint32, so we can be a lot smarter in the
typer, loosing less information upon truncation (i.e. x | 0 and x >>> 0).
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/739743003
Cr-Commit-Position: refs/heads/master@{#25412}
Reduces dependencies on #include files, making it easier for other
build systems to include this library.
BUG=
Review URL: https://codereview.chromium.org/740493002
Cr-Commit-Position: refs/heads/master@{#25408}
Without this change, `make android_arm.release.check` fails since the
unittests binary does not exist on the device.
BUG=v8:3695
LOG=
Review URL: https://codereview.chromium.org/722373003
Cr-Commit-Position: refs/heads/master@{#25405}
The clearing mechanism relies on comparing the cached handler with the installed handler. If we try to preserve monomorphism by pretending that the IC was in uninitialized state, then it will go premonomorphic first, which means on the next miss there's no installed handler available to compare against. Instead, pretend it was premonomorphic, so the comparison will happen right away, will fail as it should, and the cached handler will be cleared.
Thanks to Weiliang for starting the investigation that led to this.
R=verwaest@chromium.org
Review URL: https://codereview.chromium.org/730383002
Cr-Commit-Position: refs/heads/master@{#25394}
This essentially performs the following transformation
JSToNumber(phi(x1,...,xn,control):primitive)
=> phi(JSToNumber(x1),...,JSToNumber(xn),control):number
which is similar to what we already do for JSToBoolean.
TEST=mjsunit/asm
R=svenpanne@chromium.org
BUG=
Review URL: https://codereview.chromium.org/732463003
Cr-Commit-Position: refs/heads/master@{#25390}
We add a new ScopeType, ScopeType.Script. The scope with
ScopeType.Script is always present in the scope chain (ScopeIterator
fakes it if neededi - i.e. if ScriptContext for a script has not been
allocated since that script has no lexical declarations).
ScriptScope reflects ScriptContextTable.
R=yurys@chromium.org,yangguo@chromium.org
BUG=v8:3690
LOG=N
Review URL: https://codereview.chromium.org/726643002
Cr-Commit-Position: refs/heads/master@{#25383}
Don't use the generic algorithm, but instead start going into the
direction of ControlReducer, using a stack plus a revisit queue to
not miss any more possibilities for reductions anymore.
TEST=cctest,unittests
R=dcarney@chromium.org
Committed: f047507370
Committed: 6e148989a4
Review URL: https://codereview.chromium.org/726513002
Cr-Commit-Position: refs/heads/master@{#25377}
Now we actually implement it the way it is meant to be, that is:
JSToBoolean(Phi(x1,...,xn):primitive)
=> Phi(JSToBoolean(x1),...,JSToBoolean(xn)):boolean
This also fixes the endless recursion within JSTypedLowering when
the GraphReducer does all possible reductions instead of using the
generic algorithm.
R=dcarney@chromium.org
Review URL: https://codereview.chromium.org/730043002
Cr-Commit-Position: refs/heads/master@{#25376}
With Int32Add we lose the int/uint distinction, so later, in simplified lowering we can make a wrong decision. E.g., see the attached test case, where we lower NumberAdd -> Int32Add because inputs are Uint32, but during simplified lowering we change the inputs to Int32, so we get a wrong result.
Simplified lowering will lower the NumberAdd operations anyway, so we should lose performance.
BUG=
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/721723004
Cr-Commit-Position: refs/heads/master@{#25368}
