When Crankshaft aborts compilation, use TurboFan next time

When Crankshaft aborts compilation, use TurboFan next time

When we try to optimize a function with Crankshaft, but compilation
bails out, don't disable optimization for that function entirely,
just disable Crankshaft, so TurboFan will be used for the next attempt.

Thereby this widens the TurboFan intake valve.

Committed: https://crrev.com/4af7757fdf5199224f19a75ab060c03e86ee3fc5
Cr-Commit-Position: refs/heads/master@{#34396}

[Jakob Kummerow, 2016-03-01 13:05:45]

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

[Jakob Kummerow, 2016-03-01 13:05:45]

Benedikt: as discussed. PTAL.

Michi: FYI.

[Benedikt Meurer, 2016-03-01 13:19:35]

LGTM.

[Michael Starzinger, 2016-03-01 14:34:56]

Fine with me, just one non-actionable comment.

https://codereview.chromium.org/1751873002/diff/1/src/compiler.h
File src/compiler.h (right):

https://codereview.chromium.org/1751873002/diff/1/src/compiler.h#newcode393
src/compiler.h:393: shared_info()->set_dont_crankshaft(true);
Just for posterity: This will also disable Crankshaft for transient reasons that
might "disappear" over time (e.g. kFunctionBeingDebugged). It will also disable
Crankshaft and favor TurboFan for reasons not specific to Crankshaft (e.g.
kOptimizedTooManyTimes). This will need to be cleaned up once we try to get
compiler.cc in shape for shipping Ignition.

[Jakob Kummerow, 2016-03-01 14:40:10]

The CQ bit was checked by jkummerow@chromium.org

[commit-bot: I haz the power, 2016-03-01 14:40:13]

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

[commit-bot: I haz the power, 2016-03-01 15:13:02]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-03-01 15:14:04]

Description was changed from

==========
When Crankshaft aborts compilation, use TurboFan next time

When we try to optimize a function with Crankshaft, but compilation
bails out, don't disable optimization for that function entirely,
just disable Crankshaft, so TurboFan will be used for the next attempt.

Thereby this widens the TurboFan intake valve.
==========

to

==========
When Crankshaft aborts compilation, use TurboFan next time

When we try to optimize a function with Crankshaft, but compilation
bails out, don't disable optimization for that function entirely,
just disable Crankshaft, so TurboFan will be used for the next attempt.

Thereby this widens the TurboFan intake valve.

Committed: https://crrev.com/4af7757fdf5199224f19a75ab060c03e86ee3fc5
Cr-Commit-Position: refs/heads/master@{#34396}
==========

[commit-bot: I haz the power, 2016-03-01 15:14:05]

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

[adamk, 2016-03-01 19:15:45]

https://codereview.chromium.org/1751873002/diff/1/src/compiler.h
File src/compiler.h (right):

https://codereview.chromium.org/1751873002/diff/1/src/compiler.h#newcode393
src/compiler.h:393: shared_info()->set_dont_crankshaft(true);
On 2016/03/01 14:34:56, Michael Starzinger wrote:
> Just for posterity: This will also disable Crankshaft for transient reasons
that
> might "disappear" over time (e.g. kFunctionBeingDebugged). It will also
disable
> Crankshaft and favor TurboFan for reasons not specific to Crankshaft (e.g.
> kOptimizedTooManyTimes). This will need to be cleaned up once we try to get
> compiler.cc in shape for shipping Ignition.

The second one of these examples, kOptimizedTooManyTimes, worries me a bit: does
that have the potential to make code where we spend all our time compiling
perform even worse?

[Jakob Kummerow, 2016-03-02 15:25:52]

On 2016/03/01 19:15:45, adamk wrote:
> The second one of these examples, kOptimizedTooManyTimes, worries me a bit:
does
> that have the potential to make code where we spend all our time compiling
> perform even worse?

The idea is that turbofan-optimized code would not bail out or deopt, while
being faster than full code.
If an example turns up where this change causes a regression we'll have to
reconsider our options.

[Jakob Kummerow, 2016-03-14 10:11:23]

On 2016/03/02 15:25:52, Jakob wrote:
> The idea is that turbofan-optimized code would not bail out or deopt, while
> being faster than full code.
> If an example turns up where this change causes a regression we'll have to
> reconsider our options.

Yeah, well: https://crrev.com/864f33d7614ceb3d729c8c7d7bee9f1ee24cc715