[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