LGTM

LGTM

Here's diff I found: https://www.textcompare.org/?id=61b7080d8668ef0015be12a9
Left window is before this patch, right is after.
Seems like VPBROADCASTBZ128rm, VPCMOVYrmr, VPPERMrmr ports change from [5, 23] to [15, 23] but we didn't have list test for them.
BTW, uops.info provides lat/tpt for icelake, not icelake-server.

Another problem, do we need to add check for 64Bit?

TLI->getTypeLegalizationCost(DL, Ty) for i64 is i32. Therefore mul i64, i64 on 32bit target will fall to BaseT::getArithmeticInstrCost(Opcode, Ty, CostKind, Op1Info, Op2Info)

Can we first fix imul i64 cost for avx512 before merging D46276? It's 1 cy for all avx512 target.

A more critical feature would be to 'add' costs correctly for throughput cost kinds - depending on pipe usage etc. - instead of just numerically adding the costs together, which only makes sense for latency / size cost kinds.

We may need to fix resource_cycles for many x86 schedmodels (e.g. SKL, SKX) to get a correct throughput. Most instructions set resource_cycles to 1 for each uop which gets wrong throughput.

Move to avx512 cost table and rebase

This is a classic example of where having cost tables driven from (accurate) scheduler models would be much more useful (D46276), but there has been very little interest in helping polish those models to make that a viable option.

I think we can't completely trust reversed throughput reported by llvm-mca since some instructions' Rthroughput is not defined correctly in schedmodel.
e.g.

$./llvm_utils_check_cost_tables.py --cpulevel=avx512  --stop-on-diff
double fdiv double: cost (4.0 - 4.0) vs recipthroughput (3 - 3)
skylake-avx512 : 4.0 vs 3

defines in X86SchedSkylakeServer.td:

def SKXWriteResGroup184 : SchedWriteRes<[SKXPort0,SKXFPDivider]> {
  let Latency = 14;
  let NumMicroOps = 1;
  let ResourceCycles = [1,3];
}
def : SchedAlias<WriteFDiv64,  SKXWriteResGroup184>; // TODO - convert to ZnWriteResFpuPair

However, it's measured tpt is 4 from uops.info. llvm-exegesis tpt result is also 4.
I think uops.info/agner.org should be more accurate.