Use these check points to optimize comparisons where we already know
that one side cannot be a String (or turn into a string via
ToPrimitive).
Also remove bunch of useless DoNotCrash tests for the scheduler that are
painful to maintain and add almost no value.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1140583004
Cr-Commit-Position: refs/heads/master@{#28383}
This stub will be used as the basis of a Math.floor-specific CallIC to
detect and track calls to floor that return -0.
Along the way:
- Create a TurboFanCodeStub super class from which the StringLength and
MathRound TF stubs derive.
- Fix the ugly hack that passes the first stub parameter as the "this"
pointer in the the TF-compiled JS function.
- Fix bugs in the ia32/x64 disassembler.
Review URL: https://codereview.chromium.org/1137703002
Cr-Commit-Position: refs/heads/master@{#28339}
The goal is to port all of error stack trace formatting to C++.
We will do this bottom up, by first porting helper functions.
Eventually, CallSite methods will only be used when a custom
error stack trace formatter is defined via Error.prepareStackTrace.
R=jkummerow@chromium.org
Review URL: https://codereview.chromium.org/1060583008
Cr-Commit-Position: refs/heads/master@{#28095}
Deoptimization infrastructure already handles it correctly.
This change fixes repetitive deoptimizations in the code like this:
var u32 = new Uint32Array(1);
u32[0] = -1;
function tr(x) { return x|0; }
function ld() { return tr(u32[0]); }
while (true) ld();
Currently inlined tr will contain HArgumentsObject that is considered uint32-unsafe use and prevents u32[0] from becoming uint32 load - instead a speculative int32 load is generated which just deopts.
BUG=
Review URL: https://codereview.chromium.org/1077113002
Cr-Commit-Position: refs/heads/master@{#27781}
With this change, we remember the types of frame state inputs (in a new
operator, called TypedStateValues). Instead of inferring the value types
when building translations, we used the recorded types.
The original approach was not reliable because the passes after
simplified lowering can change node types, and this in turn confuses
the translation builder.
BUG=chromium:468727
LOG=n
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1015423002
Cr-Commit-Position: refs/heads/master@{#27310}
The change introduces a second frame state (for the state before
the operation) for the StoreProperty nodes. If the store writes
into a typed array, the frame state is used for lazy deopt from
the to-number conversion that is performed by the store.
BUG=v8:3963
LOG=n
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/997983004
Cr-Commit-Position: refs/heads/master@{#27285}
In constructing the transfer between loop copies, we need to merge the backedges from all the previous copies of the given loop. The control reduction will work out which ones are really reachable.
R=mstarzinger@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1004993004
Cr-Commit-Position: refs/heads/master@{#27246}
This makes sure only the %_DeoptimizeNow intrinsic is inlined, and
not the %DeoptimizeNow one. It hence re-establishes the invariant
that JSIntrinsicLowering only deals with inline intrinsics.
R=jarin@chromium.org
TEST=mjsunit/compiler/eager-deopt-simple
Review URL: https://codereview.chromium.org/988333003
Cr-Commit-Position: refs/heads/master@{#27070}
This just contains test, no fixes. Note that some of the tests are
still disabled because they either fail or we don't want ClusterFuzz
to pick up the flag yet.
R=jarin@chromium.org
TEST=cctest/test-run-jsexceptions/Deopt,mjsunit/compiler/try-deopt
Review URL: https://codereview.chromium.org/972943004
Cr-Commit-Position: refs/heads/master@{#26968}
This prevents eliminating effectful statements before the loop.
BUG=
Review URL: https://codereview.chromium.org/830923002
Cr-Commit-Position: refs/heads/master@{#25953}
We cannot just clear the result register optimistically, because the
register allocator might assign the same register to result and buffer.
TEST=mjsunit/compiler/regress-445858
BUG=chromium:445858
LOG=y
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/828303002
Cr-Commit-Position: refs/heads/master@{#25950}
Set a valid reason for disabling optimization when using
%NeverOptimizeFunction.
TEST=mjsunit/compiler/regress-445732
BUG=chromium:445732
LOG=y
TBR=machenbach@chromium.org
Review URL: https://codereview.chromium.org/832003002
Cr-Commit-Position: refs/heads/master@{#25949}
Change InstructionOperand to use a 64-bit field for encoding the operand
information instead of the 32-bit field that was used before. Ideally we
wouldn't use the Zone-allocated bit field at all, and use an integer
instead of the pointer; but that requires fixing the register allocator
first, which will take some time.
TEST=mjsunit/compiler/regress-3786
BUG=v8:3786
LOG=y
Review URL: https://codereview.chromium.org/826673002
Cr-Commit-Position: refs/heads/master@{#25941}
The `right == 0` checks only worked for `0 <= right < 32`. This patch
replaces the checks with simple tests for negative results.
The attached test can detect this error, but the test relies on a broken
flag (--noopt-safe-uint32-operations), so it is skipped for now. See
issue 3487 for details.
BUG=
R=ulan@chromium.org
Review URL: https://codereview.chromium.org/487913005
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@23243 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
version is passing all the existing test + a bunch of new tests
(packaged in the change list, too).
The patch extends the SlotRef object to describe captured and duplicated
objects. Since the SlotRefs are not independent of each other anymore,
there is a new SlotRefValueBuilder class that stores the SlotRefs and
later materializes the objects from the SlotRefs.
Note that unlike the previous implementation of SlotRefs, we now build
the SlotRef entries for the entire frame, not just the particular
function. This is because duplicate objects might refer to previous
captured objects (that might live inside other inlined function's part
of the frame).
We also need to store the materialized objects between other potential
invocations of the same arguments object so that we materialize each
captured object at most once. The materialized objects of frames live
in the new MaterielizedObjectStore object (contained in Isolate),
indexed by the frame's FP address. Each argument materialization (and
deoptimization) tries to lookup its captured objects in the store before
building new ones. Deoptimization also removes the materialized objects
from the store. We also schedule a lazy deopt to be sure that we always
get rid of the materialized objects and that the optmized function
adopts the materialized objects (instead of happily computing with its
captured representations).
Concerns:
- Is the FP address the right key for a frame? (Note that deoptimizer's
representation of frame is different from the argument object
materializer's one - it is not easy to find common ground.)
- Performance is suboptimal in several places, but a quick local run of
benchmarks does not seem to show a perf hit. Examples of possible
improvements: smarter generation of SlotRefs (build other functions'
SlotRefs only for captured objects and only if necessary), smarter
lookup of stored materialized objects.
- Ideally, we would like to share the code for argument materialization
with deoptimizer's materializer. However, the supporting data structures
(mainly the frame descriptor) are quite different in each case, so it
looks more like a separate project.
Thanks for any feedback.
R=danno@chromium.org, mstarzinger@chromium.org
LOG=N
BUG=
Committed: https://code.google.com/p/v8/source/detail?r=18918
Review URL: https://codereview.chromium.org/103243005
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18936 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
mostly to make sure that it is going in the right direction. The current
version is passing all the existing test + a bunch of new tests
(packaged in the change list, too).
The patch extends the SlotRef object to describe captured and duplicated
objects. Since the SlotRefs are not independent of each other anymore,
there is a new SlotRefValueBuilder class that stores the SlotRefs and
later materializes the objects from the SlotRefs.
Note that unlike the previous implementation of SlotRefs, we now build
the SlotRef entries for the entire frame, not just the particular
function. This is because duplicate objects might refer to previous
captured objects (that might live inside other inlined function's part
of the frame).
We also need to store the materialized objects between other potential
invocations of the same arguments object so that we materialize each
captured object at most once. The materialized objects of frames live
in the new MaterielizedObjectStore object (contained in Isolate),
indexed by the frame's FP address. Each argument materialization (and
deoptimization) tries to lookup its captured objects in the store before
building new ones. Deoptimization also removes the materialized objects
from the store. We also schedule a lazy deopt to be sure that we always
get rid of the materialized objects and that the optmized function
adopts the materialized objects (instead of happily computing with its
captured representations).
Concerns:
- Is there a simpler/more correct way to store the already-materialized
objects? (At the moment there is a custom root reference to JSArray
containing frames' FixedArrays with their captured objects.)
- Is the FP address the right key for a frame? (Note that deoptimizer's
representation of frame is different from the argument object
materializer's one - it is not easy to find common ground.)
- Performance is suboptimal in several places, but a quick local run of
benchmarks does not seem to show a perf hit. Examples of possible
improvements: smarter generation of SlotRefs (build other functions'
SlotRefs only for captured objects and only if necessary), smarter
lookup of stored materialized objects.
- Ideally, we would like to share the code for argument materialization
with deoptimizer's materializer. However, the supporting data structures
(mainly the frame descriptor) are quite different in each case, so it
looks more like a separate project.
Thanks for any feedback.
R=mstarzinger@chromium.org, danno@chromium.org
LOG=N
BUG=
Review URL: https://codereview.chromium.org/103243005
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18918 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
