[crankshaft] Remove for-in slow mode deopt loop.

[crankshaft] Remove for-in slow mode deopt loop.

When a slow mode for-in loop is compiled with Crankshaft we
unconditionally deoptimize when we hit an object with a usable
enum-cache (which is currently hidden by another CL), and obviously
we don't learn anything from that.

R=jarin@chromium.org
BUG=v8:3650
LOG=n

Committed: https://crrev.com/1c6a818efb0be7bc00f6ccd6bfb66fde8d7d3657
Cr-Commit-Position: refs/heads/master@{#33427}

[Benedikt Meurer, 2016-01-21 08:34:40]

Hey Jaro,

Here's the fix for the deopt loop for slow-mode for-in.
Please take a look.

Thanks,
Benedikt

[Jarin, 2016-01-21 08:47:10]

lgtm

[Benedikt Meurer, 2016-01-21 08:47:18]

The CQ bit was checked by bmeurer@chromium.org

[commit-bot: I haz the power, 2016-01-21 08:47:27]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1611933003/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1611933003/1

[commit-bot: I haz the power, 2016-01-21 08:55:58]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-01-21 08:56:36]

Description was changed from

==========
[crankshaft] Remove for-in slow mode deopt loop.

When a slow mode for-in loop is compiled with Crankshaft we
unconditionally deoptimize when we hit an object with a usable
enum-cache (which is currently hidden by another CL), and obviously
we don't learn anything from that.

R=jarin@chromium.org
BUG=v8:3650
LOG=n
==========

to

==========
[crankshaft] Remove for-in slow mode deopt loop.

When a slow mode for-in loop is compiled with Crankshaft we
unconditionally deoptimize when we hit an object with a usable
enum-cache (which is currently hidden by another CL), and obviously
we don't learn anything from that.

R=jarin@chromium.org
BUG=v8:3650
LOG=n

Committed: https://crrev.com/1c6a818efb0be7bc00f6ccd6bfb66fde8d7d3657
Cr-Commit-Position: refs/heads/master@{#33427}
==========

[commit-bot: I haz the power, 2016-01-21 08:56:36]

Patchset 1 (id:??) landed as
https://crrev.com/1c6a818efb0be7bc00f6ccd6bfb66fde8d7d3657
Cr-Commit-Position: refs/heads/master@{#33427}

[adamk, 2016-01-21 22:13:24]

The buildbot history suggests that this patch, with cbruni's revert of his "Do
not use enum-cache in for-in" patch, causes the Deopt fuzzer to consistently
fail: 

https://build.chromium.org/p/client.v8/builders/V8%20Deopt%20Fuzzer/builds/7442
https://build.chromium.org/p/client.v8/builders/V8%20Deopt%20Fuzzer/builds/7443
https://build.chromium.org/p/client.v8/builders/V8%20Deopt%20Fuzzer/builds/7444

etc

Please take a look (I'm not totally clear on the connections between these
different for-in patches).

[Benedikt Meurer, 2016-01-22 04:56:20]

Thanks for the hint, will investigate. Camillo's patch essentially disabled the
enum cache in many cases.

[Jakob Kummerow, 2016-01-28 21:34:37]

jkummerow@chromium.org changed reviewers:
+ jkummerow@chromium.org

[Jakob Kummerow, 2016-01-28 21:34:38]

This CL introduced https://bugs.chromium.org/p/v8/issues/detail?id=4715 .

https://codereview.chromium.org/1611933003/diff/1/src/crankshaft/hydrogen.cc
File src/crankshaft/hydrogen.cc (right):

https://codereview.chromium.org/1611933003/diff/1/src/crankshaft/hydrogen.cc#...
src/crankshaft/hydrogen.cc:5354: Push(cache_map);
Pushing the map here has no effect, as we're in the fast==false case (see lines
5322/5337 above), whereas the map check that would consume it is only emitted in
the fast==true case (see line 5412 below).