Tests that carefully checks opt/deopt status shouldn't --always-opt.
authormvstanton <mvstanton@chromium.org>
Wed, 8 Apr 2015 15:55:58 +0000 (08:55 -0700)
committerCommit bot <commit-bot@chromium.org>
Wed, 8 Apr 2015 15:56:01 +0000 (15:56 +0000)
commitaf293729ad51cbf611584d898733964bf0bec5e4
tree270616d0f29d0984fab9d8303d04fc9d0d32d7f2
parent515e483dd0f468226715f0ea9826dd568a56a27b
Tests that carefully checks opt/deopt status shouldn't --always-opt.

If we optimize a function before gathering feedback it may be
peppered with soft deoptimizations. So it can't help but deoptimize.
A judicious reading of the code isn't enough to determine what the
optimization state should be in the face of such chaotic gyrations.

BUG=
R=verwaest@chromium.org

Review URL: https://codereview.chromium.org/1069363003

Cr-Commit-Position: refs/heads/master@{#27671}
test/mjsunit/double-intrinsics.js
test/mjsunit/es6/block-let-crankshaft.js