[PATCH] D38279: [MachineScheduler] Enable latency heuristic based on scheduled lat.
Florian Hahn via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Tue Nov 28 11:21:13 PST 2017
fhahn added a comment.
In https://reviews.llvm.org/D38279#937309, @jonpa wrote:
> This makes sense to me as well, but I wonder why Issued gets a different value depending on top/bot ?
My understanding was current cycle is quite accurate from top-down, but not for bottom up. For example, after scheduling a node with latency 3 from bottom, we would only bump CurrCycle to 1. But if this node is on the critical path, scheduling the predecessor in the next cycle increases the critical path by 2 cycles (if we there are enough remaining instructions to be scheduled), because it was scheduled too early.
When going top-down, only after CurrCycle + RemLatency > CriticalPath scheduling a node later would increase the critical path.
Another way to think about it: When going top down, scheduling a node on the critical path “too early” does not have any impact on that critical path (it might cause another path to become critical though). But scheduling a node on the critical path “too early” when going bottom up is worse, as each instruction scheduled after the node increases the critical path ( assuming we can issue 1 instruction per cycle).
================
Comment at: lib/CodeGen/MachineScheduler.cpp:2445
+ unsigned Issued = CurrZone.isTop() ? CurrZone.getCurrCycle() :
+ CurrZone.getScheduledLatency();
+ if (IsPostRA || (RemLatency + Issued > Rem.CriticalPath)) {
----------------
javed.absar wrote:
> Bit strange. getScheduledLatency returns max of CurrCycle and ExpectedLatency which I dont quite find set anywhere (other than 0).
It's updated in `bumpNode`, through the reference created at line 2230 I think.
https://reviews.llvm.org/D38279
More information about the llvm-commits
mailing list