Change these schedulers to not emit no-ops. It turns out that

the RR scheduler actually does look at latency values, but it
doesn't use a hazard recognizer so it has no way to know when
a no-op is needed, as opposed to just stalling and incrementing
the cycle count.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@59759 91177308-0d34-0410-b5e6-96231b3b80d8
This commit is contained in:
Dan Gohman 2008-11-21 00:10:42 +00:00
parent 66c75aaa02
commit 47d1a214a7
2 changed files with 3 additions and 9 deletions

View File

@ -577,9 +577,7 @@ void ScheduleDAGFast::ListScheduleBottomUp() {
} }
NotReady.clear(); NotReady.clear();
if (!CurSU) if (CurSU)
Sequence.push_back(0);
else
ScheduleNodeBottomUp(CurSU, CurCycle); ScheduleNodeBottomUp(CurSU, CurCycle);
++CurCycle; ++CurCycle;
} }

View File

@ -1052,9 +1052,7 @@ void ScheduleDAGRRList::ListScheduleBottomUp() {
} }
NotReady.clear(); NotReady.clear();
if (!CurSU) if (CurSU)
Sequence.push_back(0);
else
ScheduleNodeBottomUp(CurSU, CurCycle); ScheduleNodeBottomUp(CurSU, CurCycle);
++CurCycle; ++CurCycle;
} }
@ -1152,9 +1150,7 @@ void ScheduleDAGRRList::ListScheduleTopDown() {
AvailableQueue->push_all(NotReady); AvailableQueue->push_all(NotReady);
NotReady.clear(); NotReady.clear();
if (!CurSU) if (CurSU)
Sequence.push_back(0);
else
ScheduleNodeTopDown(CurSU, CurCycle); ScheduleNodeTopDown(CurSU, CurCycle);
++CurCycle; ++CurCycle;
} }