Hi,
Regarding the mischeduler, I wonder
// For loops that are acyclic path limited, aggressively schedule for
// latency. This can result in very long dependence chains scheduled in
// sequence, so once every cycle (when CurrMOps == 0), switch to normal
// heuristics.
if (Rem.IsAcyclicLatencyLimited && !Zone->getCurrMOps() &&
tryLatency(TryCand, Cand, *Zone))
return;
Is this an error in comment or code? The CurrMOps is 0 once per cycle,
which means
this is actually done once per cycle, in contrast to what the comment
suggests.
...
// Schedule aggressively for latency in PostRA mode. We don't check for
// acyclic latency during PostRA, and highly out-of-order processors will
// skip PostRA scheduling.
if (!OtherResLimited) {
if (IsPostRA || (RemLatency + CurrZone.getCurrCycle() >
Rem.CriticalPath)) {
Policy.ReduceLatency |= true;
Why !OtherResLimited? tryCandidate() has already checked for resource
balancing just
before this. To not do the latency check then only means falling back to
original
order.
/Jonas
> On Oct 28, 2016, at 3:04 AM, Jonas Paulsson via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi, > > Regarding the mischeduler, I wonder > > // For loops that are acyclic path limited, aggressively schedule for > // latency. This can result in very long dependence chains scheduled in > // sequence, so once every cycle (when CurrMOps == 0), switch to normal > // heuristics. > if (Rem.IsAcyclicLatencyLimited && !Zone->getCurrMOps() && > tryLatency(TryCand, Cand, *Zone)) > return; > > Is this an error in comment or code? The CurrMOps is 0 once per cycle, which means > this is actually done once per cycle, in contrast to what the comment suggests.Intuitively, I think the code is sensible and the comment misleading. It should probably say something like: For loops that are acyclic path limited, aggressively schedule for latency. Within an single cycle, whenever CurrMOps > 0, allow normal heuristics to take precedence.> ... > > // Schedule aggressively for latency in PostRA mode. We don't check for > // acyclic latency during PostRA, and highly out-of-order processors will > // skip PostRA scheduling. > if (!OtherResLimited) { > if (IsPostRA || (RemLatency + CurrZone.getCurrCycle() > Rem.CriticalPath)) { > Policy.ReduceLatency |= true; > > > Why !OtherResLimited? tryCandidate() has already checked for resource balancing just > before this. To not do the latency check then only means falling back to original > order.The concept here is to aggressively prioritize scheduling for latency in PostRA mode—unless the unscheduled instructions are clearly resource limited. I agree with your comment. Not sure what your question is ;) -Andy> /Jonas > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Hi Andy,> Intuitively, I think the code is sensible and the comment misleading. It should probably say something like: > > For loops that are acyclic path limited, aggressively schedule for latency. Within an single cycle, whenever CurrMOps > 0, allow normal heuristics to take precedence.I changed the comment -- see attached patch.> The concept here is to aggressively prioritize scheduling for latency in PostRA mode—unless the unscheduled instructions are clearly resource limited. I agree with your comment. Not sure what your question is ;)That's actually making sense to me now - sorry. I was confusing "policy" and "candidate evaluation". /Jonas -------------- next part -------------- A non-text attachment was scrubbed... Name: MISched_comment_acycliclat.patch Type: text/x-patch Size: 820 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161103/b0262cf7/attachment.bin>