[X86][MCA] Address the latest issues with MULX reported in PR51495.
authorAndrea Di Biagio <andrea.dibiagio@sony.com>
Wed, 25 Aug 2021 20:34:35 +0000 (21:34 +0100)
committerAndrea Di Biagio <andrea.dibiagio@sony.com>
Thu, 26 Aug 2021 11:08:20 +0000 (12:08 +0100)
commit4a5b191703978a56ff6dcbae0e0bcb6b8933adfc
tree3cae3ecc1eb7fa1b620be202325a70b43947413b
parentb475ce39e8b1de3a70ea242473f136a567be46e3
[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
llvm/lib/MCA/HardwareUnits/RegisterFile.cpp
llvm/lib/Target/X86/X86InstrArithmetic.td
llvm/lib/Target/X86/X86SchedBroadwell.td
llvm/lib/Target/X86/X86SchedHaswell.td
llvm/lib/Target/X86/X86SchedSandyBridge.td
llvm/lib/Target/X86/X86SchedSkylakeClient.td
llvm/lib/Target/X86/X86SchedSkylakeServer.td
llvm/test/tools/llvm-mca/X86/Haswell/mulx-same-regs.s
llvm/test/tools/llvm-mca/X86/SkylakeClient/mulx-same-regs.s