[PATCH] D49436: [X86][BtVer2] correctly model the latency/throughput of LEA instructions.

Andrea Di Biagio via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Jul 17 10:37:36 PDT 2018


andreadb created this revision.
andreadb added reviewers: RKSimon, craig.topper, spatel, mattd, courbet, ab.
Herald added a subscriber: gbedwell.

This patch fixes the latency/throughput of LEA instructions in the BtVer2 scheduling model.

On Jaguar, A 3-operands LEA has a latency of 2cy, and a reciprocal throughput of 1.
That is because it uses one cycle of SAGU followed by 1cy of ALU1.

An LEA with a "Scale" operand is also slow, and it has the same latency profile as the 3-operands LEA.
An LEA16r has a latency of 3cy, and a throughput of 0.5 (i.e. RThrouhgput of 2.0).

This patch adds a new TIIPredicate named `IsThreeOperandsLEAFn` to X86Schedule.td.
The tablegen backend (for instruction-info) expands that definition into this (file X86GenInstrInfo.inc):

  static bool isThreeOperandsLEA(const MachineInstr &MI) {
    return (
      MI.getOperand(1).isReg()
      && MI.getOperand(1).getReg() != 0
      && MI.getOperand(3).isReg()
      && MI.getOperand(3).getReg() != 0
      && (
        (
          MI.getOperand(4).isImm()
          && MI.getOperand(4).getImm() != 0
        )
        || (MI.getOperand(4).isGlobal())
      )
    );
  }

A similar method is generated in the X86_MC namespace, and included into X86MCTargetDesc.cpp (the declaration lives in X86MCTargetDesc.h).

Back to the BtVer2 scheduling model:
A new scheduling predicate named `JSlowLEAPredicate` now checks if either the instruction is a three-operands LEA, or it is an LEA with a Scale value different than 1.
A variant scheduling class uses that new predicate to correctly select the appropriate latency profile.

This patch is essentially structured in two parts:

- A first part that adds a common MCPredicate to X86Schedule.td
- A second part that uses the new predicate to construct a variant class for LEA in the BtVer2 model only.

To help the implementation of part 1, the predicate expanded gained the ability to check if a register operand references the invalid register. That check is needed by `IsThreeOperandsLEAFn`.

This new TII hook can now be used in other parts of LLVM.
For example, this patch uses it in X86FixupLEA.cpp. Note that the auto-generated `isThreeOperandsLEA()` is semantically equivalent to the old function in X86FixupLEA.cpp.

As a side note: if people prefer, this patch can be committed in two revisions. The first part would be an NFC, while the second part would contain the actual change to the BtVer2 model.

Please let me know what you think.

Thanks
-Andrea


https://reviews.llvm.org/D49436

Files:
  include/llvm/Target/TargetInstrPredicate.td
  lib/Target/X86/MCTargetDesc/X86MCTargetDesc.cpp
  lib/Target/X86/MCTargetDesc/X86MCTargetDesc.h
  lib/Target/X86/X86FixupLEAs.cpp
  lib/Target/X86/X86Schedule.td
  lib/Target/X86/X86ScheduleBtVer2.td
  test/CodeGen/X86/lea32-schedule.ll
  test/CodeGen/X86/lea64-schedule.ll
  test/CodeGen/X86/mul-constant-i32.ll
  test/CodeGen/X86/mul-constant-i64.ll
  test/tools/llvm-mca/X86/BtVer2/resources-lea.s
  utils/TableGen/PredicateExpander.cpp
  utils/TableGen/PredicateExpander.h

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D49436.155911.patch
Type: text/x-patch
Size: 62130 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20180717/3b2413ca/attachment.bin>


More information about the llvm-commits mailing list