[LLVMdev] MISched: Difference between Latency and ResourceCycles

Andrew Trick atrick at apple.com
Wed Apr 15 10:32:03 PDT 2015


> On Apr 14, 2015, at 7:03 PM, Tom Stellard <tom at stellard.net> wrote:
> 
> Hi,
> 
> The ProcWriteResources Tablegen class has a Latency member variable and a
> ProcResources member variable.  What is the difference between these
> two?  If I have an instruction that spends 5 cycles in resource A
> and then 5 cycles in resource B, how should I be setting these variables?

Latency affects heuristics that attempt to shorten the critical path. This determines the depth/height of DAG nodes.

Resource cycles affect heuristics that reduce resource constraints or avoid resources conflicts. For an in-order model, this takes higher priority than out-of-order of course.

The operand-level machine model doesn’t describe each stage of the pipeline. The full itineraries can do that. This is explained a bit in TargetSchedule.td. Modeling each stage of the pipeline is expensive (that’s done via the reservation table that the hazard checker uses) and almost never matters. That’s why it’s encouraged to start with a per-operand model. If you give your subtarget an itinerary, the more expensive hazard checker will run.

If resource B is usually used 5 cycles after the instruction issues, then simply modeling the number of cycles that resource B is used is sufficient (you don’t need to model the fact that it is shifted in time relative to resource A, since it doesn’t conflict with resource A).

That said, it wouldn’t be difficult to add the concept of a delayed resource constraint to the per-operand model. A simple time shift could be handled without resorting to a reservation table. This has come up at least once before but was never important enough for me to implement.

Andy

> 
> Thanks,
> Tom
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev





More information about the llvm-dev mailing list