[es7] bailout Crankshaft in VisitDoExpression

[es7] bailout Crankshaft in VisitDoExpression

For some reason, the DisableCrankshaft() in ast-numbering.cc does not always
prevent crankshaft from happening. Bailout here rather than asserting an
unreachable condition.

BUG=546967, v8:4488
LOG=N
R=bmeurer@chromium.org

Committed: https://crrev.com/b078960e70039b9c63754d9bb0948418cbdc43f6
Cr-Commit-Position: refs/heads/master@{#31537}

[caitp (gmail), 2015-10-23 18:53:14]

PTAL, fixes one of the fuzz failures.

[rossberg, 2015-10-23 20:15:32]

Description was changed from

==========
[es7] bailout Crankshaft in VisitDoExpression

For some reason, the DisableCrankshaft() in ast-numbering.cc does not always
prevent crankshaft from happening. Bailout here rather than asserting an
unreachable condition.

BUG=546967, v8:4488
LOG=N
R=rossberg@chromium.org, hablich@chromium.org, adamk@chromium.org,
wingo@igalia.com
==========

to

==========
[es7] bailout Crankshaft in VisitDoExpression

For some reason, the DisableCrankshaft() in ast-numbering.cc does not always
prevent crankshaft from happening. Bailout here rather than asserting an
unreachable condition.

BUG=546967, v8:4488
LOG=N
R=rossberg@chromium.org, hablich@chromium.org, adamk@chromium.org,
wingo@igalia.com
==========

[rossberg, 2015-10-23 20:15:32]

rossberg@chromium.org changed reviewers:
+ bmeurer@chromium.org

[rossberg, 2015-10-23 20:15:32]

rossberg@chromium.org changed required reviewers:
+ bmeurer@chromium.org

[rossberg, 2015-10-23 20:16:07]

Description was changed from

==========
[es7] bailout Crankshaft in VisitDoExpression

For some reason, the DisableCrankshaft() in ast-numbering.cc does not always
prevent crankshaft from happening. Bailout here rather than asserting an
unreachable condition.

BUG=546967, v8:4488
LOG=N
R=rossberg@chromium.org, hablich@chromium.org, adamk@chromium.org,
wingo@igalia.com
==========

to

==========
[es7] bailout Crankshaft in VisitDoExpression

For some reason, the DisableCrankshaft() in ast-numbering.cc does not always
prevent crankshaft from happening. Bailout here rather than asserting an
unreachable condition.

BUG=546967, v8:4488
LOG=N
R=bmeurer@chromium.org
==========

[rossberg, 2015-10-23 20:16:07]

rossberg@chromium.org changed reviewers:
- adamk@chromium.org, hablich@chromium.org, rossberg@chromium.org,
wingo@igalia.com

[rossberg, 2015-10-23 20:16:40]

Reassigned to Crankshaft owner.

[caitp (gmail), 2015-10-23 20:17:24]

On 2015/10/23 20:16:40, rossberg wrote:
> Reassigned to Crankshaft owner.

didn't know anyone still owned it, my bad

[Benedikt Meurer, 2015-10-24 06:44:54]

The CQ bit was checked by bmeurer@chromium.org

[Benedikt Meurer, 2015-10-24 06:44:54]

lgtm

[commit-bot: I haz the power, 2015-10-24 06:44:58]

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

[commit-bot: I haz the power, 2015-10-24 07:06:33]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2015-10-24 07:07:09]

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

[adamk, 2015-10-26 17:53:12]

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

[adamk, 2015-10-26 17:53:12]

Is there any background on why exactly ast-numbering doesn't work here?

[caitp (gmail), 2015-10-26 17:54:44]

On 2015/10/26 17:53:12, adamk wrote:
> Is there any background on why exactly ast-numbering doesn't work here?

Probably some combination of flags that wound up forcing crankshaft compilation
despite the disabled optimization

[caitp (gmail), 2015-10-26 17:59:17]

On 2015/10/26 17:54:44, caitp wrote:
> On 2015/10/26 17:53:12, adamk wrote:
> > Is there any background on why exactly ast-numbering doesn't work here?
> 
> Probably some combination of flags that wound up forcing crankshaft
compilation
> despite the disabled optimization

I'm wrong, the test case points this out pretty clearly. Presumably
%OptimizeFunctionOnNextCall(__f_1); doesn't care if optimization is disabled,
which is probably a separate bug.