[PATCH] D130959: [X86] Add schedule module for Alderlake target

Haohai, Wen via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Aug 2 06:13:42 PDT 2022


HaohaiWen added a comment.

> do you have enough public info to write the model manually and then exegesis can confirm it at least matches total uops, throughput and latency counts.

For total uops, latency, we can get them from uops.info. We can set them in schedule model automatically.
For throughput, llvm calculate (see MCSchedModel::getReciprocalThroughput) them based on port description (resource, resource_cycles) instead of defining them directly like latency. We need to infer possible ports based on given throughput.

In fact, for resource_cycles, we don't have chance to measure each uop's latency for any intel x86 processors. I noticed skylake model made a assumption that each uop consume 1 cycle. That means throughput inferred from skylake schedule model may be inaccurate. I guess that's why skylake model has dummy ports called SKLDivider and SKLFPDivider and it may be used to get right throughput. In this alderlake-p model, I also defined each uop consume 1 cycle. I know that's not accurate but I don't have a better workaround.
I don't know whether we can measure resouce_cycles for other arch, but for x86, I think we can't get this. Because of this limitation, can we manually define a identifier called "Throughput" like "Latency/NumMicroOps" so that getReciprocalThroughput can return it if "Throughput" has defined or calculate based on port deception if not defined?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D130959/new/

https://reviews.llvm.org/D130959



More information about the llvm-commits mailing list