| Issue |
209145
|
| Summary |
[X86] Recent Intel client CPUs still use the Alder Lake-P schedule model; X86SchedLunarlakeP.td is only wired to lunarlake and contains inconsistent data
|
| Labels |
new issue
|
| Assignees |
|
| Reporter |
secondeblue-snu
|
Re-filed from intel/llvm#22610 at that repo's maintainers' request (CPU scheduling work happens upstream).
Coverage status (verified in current main):
- X86SchedLunarlakeP.td was added in #139446 (June 2025), but only -mcpu=lunarlake is wired to LunarlakePModel (X86.td).
- "arrowlake" and "arrowlake-s" ship the same Lion Cove / Skymont cores as Lunar Lake, yet remain on AlderlakePModel (2021, Golden Cove based).
- "pantherlake" (Cougar Cove, a Lion Cove derivative) and "novalake" also remain on AlderlakePModel.
- There is no E-core scheduling model at all: "clearwaterforest" is an E-core-only (Darkmont) part currently scheduled with a P-core-derived model.
- "lunarlake" itself still reuses ProcessorFeatures.ADLTuning for its tuning flags.
Data consistency inside X86SchedLunarlakeP.td:
- MicroOpBufferSize = 792 with the comment "Based on size of ROB". Intel's own Lion Cove disclosure and independent measurement (Anton Ertl's robsize) both give a 576-entry ROB. Is 792 intentional (e.g. modeling an effective in-flight window) or an error? If intentional, a clarifying comment would help.
- The "INT EU has 112 reservation stations" comment sits next to BufferSize = 110.
- "TODO: 6 Cycle latency for Vec load comes from ADL"; several MaxLatency = 100 placeholders; in the "Manual Regressive" section scalar FP adds (ADDSS/SUBSSrr) are mapped to the integer-ALU port group. CompleteModel = 0 is understood; these look like carryovers rather than modeling choices.
Questions:
1. Is wiring arrowlake/arrowlake-s (and pantherlake) to LunarlakePModel, or to dedicated models, planned?
2. Is a Skymont/Darkmont E-core model planned, particularly for clearwaterforest?
3. Can the MicroOpBufferSize discrepancy be clarified or corrected?
Context, one line: the public Optimization Reference Manual (doc 248966, rev 050, April 2024) documents none of these cores, so this .td is effectively the most detailed public out-of-order-resource data for Lion Cove, which raises the value of its correctness beyond LLVM itself.
cc @Mahesh-Attarde @phoebewang @RKSimon
![]()
_______________________________________________
llvm-bugs mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
