llvm dev - Apr 2015 - [LLVMdev] MISched: Difference between Latency and ResourceCycles

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?

Thanks,
Tom

Hi Tom,

Andy could give a more educated answer. I’ve CC’ed him.
> 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?
I guess you already noticed, but the documentation for all those variables is in
include/llvm//Target/TargetSchedule.td.

Here is my understanding of all of that.

The ProcResources tells how long/many resources you use.
E.g., if you say 5 A, this either means you use resource A for 5 cycles or you
use 5 resource A for 1 cycle. The actual semantic then depends on how many A
resources you have.

The Latency tells you how long you have to wait before the result is avialable.
E.g., if you say 5 A, latency 10. It means whatever how you consumes the 5 A
resources, the results will be available in 10 cycles.
>  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?
AFAICT, our model is not precise enough to describe that. I.e., you cannot model
the pipeline within one resource. I guess you have to resort on the itineraries
model if you want that.
The approximation I would do would look like:
// Say that we have one resource of A and one resource of B.
def ResA : ProcResource<1>;
def ResB : ProcResource<1>;

// Use 5 A then 5 B.
def : WriteRes<Write5A5B, [ResA, ResB]> {
  let Latency = 10;  // Model the A then B, by adding their cycles
  let ResourceCycles = [5, 5];
}

If you have more than one resource A or B, this is obviously not accurate.

Cheers,
-Quentin
> 
> Thanks,
> Tom
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150415/4ce1d675/attachment.html>

> 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