[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