[all-commits] [llvm/llvm-project] 8ae2a1: [X86] Use proxy scheduler models for bdver3/bdver4...

[Simon Pilgrim via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 8ae2a18736c15e0d0d9d0893b21bce4f3bf581c9
      https://github.com/llvm/llvm-project/commit/8ae2a18736c15e0d0d9d0893b21bce4f3bf581c9
  Author: Simon Pilgrim <llvm-dev at redking.me.uk>
  Date:   2024-11-13 (Wed, 13 Nov 2024)

  Changed paths:
    M llvm/lib/Target/X86/X86.td
    M llvm/test/CodeGen/X86/lwp-intrinsics.ll
    M llvm/test/CodeGen/X86/rotate_vec.ll

  Log Message:
  -----------
  [X86] Use proxy scheduler models for bdver3/bdver4 cpus (#114873)

We don't have specific models for bdver3/bdver4 cpus but we can use the
bdver2/znver1 models as proxy standins - these days the models are more
useful for analysis than for perfect instruction scheduling so these
should be fine.

While they don't accurately represent the bdver3/bdver4 architecture
(specifically the different fp-pipe layout), they give more accurate
latency/throughputs (vs Agner) than the default SandyBridge model, and
enable PostRA scheduling which all recent AMD models have benefitted
from.

I had to use the znver1 model for bdver4 so that we have AVX2
instruction coverage (none of the TBM/XOP/LWP/FMA4 instructions have
explicit schedules so this shouldn't be a problem) - they both
double-pump 256-bit instructions so this works pretty well.

This patch is based off a discussion at the devmtg regarding how easily
we can provide an actual scheduler model (or at least approximation) to
more of the X86 cpu targets - we can then add specific models if the
(unlikely) need arises.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications