[llvm-dev] mischeduler
Andrew Trick via llvm-dev
llvm-dev at lists.llvm.org
Wed Nov 2 22:41:06 PDT 2016
> 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
More information about the llvm-dev
mailing list