[llvm] [X86][SchedModel] Add Znver4/Znver5 masked gather/scatter overrides (PR #212997)

[Simon Pilgrim via llvm-commits]

================
@@ -509,6 +509,111 @@ defm : Zn4WriteResInt<WriteLoad, [Zn4AGU012, Zn4Load], !add(Znver4Model.LoadLate
 // Does not cost anything by itself, only has latency, matching that of the WriteLoad,
 defm : Zn4WriteResInt<WriteVecMaskedGatherWriteback, [], !add(Znver4Model.LoadLatency, 1), [], 0>;
 
+// AVX-512 masked GATHER / SCATTER, per shape.
+//
+// Zen4/Zen5 implement these as microcoded sequences (~4-5 macro-ops per
+// element), so the cost is a function of the number of elements and the
+// element width, not of the index width. Throughput and uops were measured on
+// Znver5 (Ryzen 9 9950X, which reuses Znver4Model) with mask-reloading
+// microbenchmarks under perf:
+//   shape   gather: tput(cyc) uops lat    scatter: tput(cyc) uops
+//   v4x32             4.0      20  17               6.0      28
+//   v8x32             6.2      33  23               9.0      49
+//   v16x32           12.7      65  30              17.0      89
+//   v4x64             4.0      20  19               5.0      28
+//   v8x64             8.0      41  25               9.0      49
+// Reciprocal throughput is reproduced through load-pipe (Zn4Load, 3 units) /
+// store-pipe (Zn4Store, 2 units) and AGU (Zn4AGU012, 3 units) occupancy:
+// ReleaseAtCycles = round(tput * NumUnits). Scatter latency is estimated
+// (throughput and uops are measured).
+//
+// Each entry is keyed by (#elements, element width); the dword- and
+// qword-index encodings of a shape share it (e.g. VPGATHERDQ and VPGATHERQQ
+// for 8 x i64). The 2-element (128-bit) shapes are force-scalarised by the
+// vectoriser and were not measured; their values are extrapolated as half the
+// 4-element entry and exist only so llvm-mca stays self-consistent.
+def Zn4WriteVPGATHERQDZ128 : SchedWriteRes<[Zn4AGU012, Zn4Load]> {
----------------
RKSimon wrote:

No FPU pipe usage?

https://github.com/llvm/llvm-project/pull/212997