[all-commits] [llvm/llvm-project] 4a5b19: [X86][MCA] Address the latest issues with MULX rep...

[Andrea Di Biagio via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 4a5b191703978a56ff6dcbae0e0bcb6b8933adfc
      https://github.com/llvm/llvm-project/commit/4a5b191703978a56ff6dcbae0e0bcb6b8933adfc
  Author: Andrea Di Biagio <andrea.dibiagio at sony.com>
  Date:   2021-08-26 (Thu, 26 Aug 2021)

  Changed paths:
    M llvm/lib/MCA/HardwareUnits/RegisterFile.cpp
    M llvm/lib/Target/X86/X86InstrArithmetic.td
    M llvm/lib/Target/X86/X86SchedBroadwell.td
    M llvm/lib/Target/X86/X86SchedHaswell.td
    M llvm/lib/Target/X86/X86SchedSandyBridge.td
    M llvm/lib/Target/X86/X86SchedSkylakeClient.td
    M llvm/lib/Target/X86/X86SchedSkylakeServer.td
    M llvm/test/tools/llvm-mca/X86/Haswell/mulx-same-regs.s
    M llvm/test/tools/llvm-mca/X86/SkylakeClient/mulx-same-regs.s

  Log Message:
  -----------
  [X86][MCA] Address the latest issues with MULX reported in PR51495.

It turns out that SchedWrite WriteIMulH was always assigned to the low half of
the result of a MULX (rather than to the high half).

To avoid confusion, this patch swaps the two MULX writes in the tablegen
definition of MULX32/64.  That way, write names better describe what they
actually refer to; this also avoids further complications if in future we decide
to reuse the same MulH writes to also model other scalar integer multiply
instructions.  I also had to swap the latency values for the two MULX writes to
make sure that the change is effectively an NFC. In fact, none of the existing
x86 tests were affected by this small refactoring.

This patch also fixes a bug in MCA: a wrong latency value was propagated for
instructions that perform multiple writes to a same register.  This last issue
was found by Roman while testing MULX on targets that define a different latency
for the Low/High part of the result.

Differential Revision: https://reviews.llvm.org/D108727