[turbofan] Propagate "deferredness" to dominated basic blocks.

[turbofan] Propagate "deferredness" to dominated basic blocks.

TEST=cctest/test-scheduler
R=mstarzinger@chromium.org

Committed: https://code.google.com/p/v8/source/detail?r=25141

[Benedikt Meurer, 2014-11-05 05:32:44]

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

[Benedikt Meurer, 2014-11-05 05:32:45]

PTAL

[Benedikt Meurer, 2014-11-05 09:10:41]

bmeurer@chromium.org changed reviewers:
+ mstarzinger@chromium.org
- jarin@chromium.org

[Benedikt Meurer, 2014-11-05 09:10:41]

Forwarding to Michi.

[Michael Starzinger, 2014-11-05 10:06:09]

Please rebase this onto https://codereview.chromium.org/696363002/ after I
landed it, then this CL should essentially turn into a one-line change.

https://codereview.chromium.org/686273005/diff/1/src/compiler/scheduler.cc
File src/compiler/scheduler.cc (right):

https://codereview.chromium.org/686273005/diff/1/src/compiler/scheduler.cc#ne...
src/compiler/scheduler.cc:535: void ComputeAssemblyOrder() {
There is a call to this method missing for the normal scheduler pipeline, the
two calls below only cover the side-channel for the raw machine assembler and
the floating control fusion.

https://codereview.chromium.org/686273005/diff/1/src/compiler/scheduler.cc#ne...
src/compiler/scheduler.cc:769:
l->block->set_ao_number(static_cast<int>(final_order->size()));
This gives you the RPO numbers, not the AO numbers.

[Michael Starzinger, 2014-11-05 10:40:12]

LGTM, just a nit.

https://codereview.chromium.org/686273005/diff/20001/src/compiler/scheduler.cc
File src/compiler/scheduler.cc (right):

https://codereview.chromium.org/686273005/diff/20001/src/compiler/scheduler.c...
src/compiler/scheduler.cc:1065: if (dominator->deferred())
current->set_deferred(true);
nit: Please move this to before the tracing (i.e. two lines up).

[Benedikt Meurer, 2014-11-05 10:43:49]

Committed patchset #3 (id:40001) manually as 25141 (presubmit successful).

[Michael Starzinger, 2014-11-05 10:52:23]

One follow-up comment about the test case.

https://codereview.chromium.org/686273005/diff/20001/test/cctest/compiler/tes...
File test/cctest/compiler/test-scheduler.cc (right):

https://codereview.chromium.org/686273005/diff/20001/test/cctest/compiler/tes...
test/cctest/compiler/test-scheduler.cc:169: block->set_deferred(i & 1);
As discussed offline: This test isn't particularly useful, because these blocks
form a chain and almost all of them will end up being deferred. Maybe we should
revert this line and add one specific test case that tests the propagation of
the "deferredness" explicitly.