[tblgen][llvm-mca] Add the ability to describe move elimination candidates via tablegen.

Authored by andreadb on Thu, Oct 11, 5:25 AM.



This patch adds the ability to identify instructions that are "move elimination candidates". It also allows scheduling models to describe processor register files that allow move elimination.

A move elimination candidate is an instruction that can be eliminated at register renaming stage.
Each subtarget can specify which instructions are move elimination candidates with the help of tablegen class "IsOptimizableMoveFunction" (see llvm/Target/TargetInstrPredicate.td).

For example, on X86, BtVer2 allows MMX/SSE moves to be eliminated only if source and destination are not the same register. The definition of 'IsOptimizableMoveFunction' for BtVer2 looks like this:

def : IsOptimizableMoveFunction<[
    // MMX variants.

    // SSE variants.

    // AVX variants.
  ], CheckNot<CheckSameRegOperand<0, 1>> >

Definitions of IsOptimizableMoveFunction from different processors of a same Target are used by the SubtargetEmitter to auto-generate target-specific overrides for the following predicate methods:

bool TargetSubtargetInfo::isOptimizableRegisterMove(const MachineInstr *MI) const;
bool MCInstrAnalysis::isOptimizableRegisterMove(const MCInst &MI, unsigned CPUID) const;

By default, those methods return false (i.e. no move elimination is allowed by the subtarget).

Tablegen class RegisterFile has been extended with the following information:

  • The set of register classes that allow move elimination.
  • Maxium number of moves that can be eliminated every cycle.
  • Whether move elimination is restricted to moves from registers that are known to be zero.

This patch is structured in three part:

A first part (which is mostly boilerplate) adds the new 'isOptimizableRegisterMove' target hooks, and extends existing register file descriptors in MC by introducing new fields to describe properties related to move elimination.

A second part, uses the new tablegen constructs to describe move elimination in the BtVer2 scheduling model.

A third part, teaches llm-mca how to query the new 'isOptimizableRegisterMove' hook to mark instructions that are candidates for move elimination. It also teaches class RegisterFile how to describe constraints on move elimination at PRF granularity.

llvm-mca tests for btver2 show differences before/after this patch.

Please let me know if okay to commit.


Diff Detail

andreadb created this revision.Thu, Oct 11, 5:25 AM
andreadb updated this revision to Diff 169213.Thu, Oct 11, 8:08 AM

Patch updated:

It turns out that on Btver2, same register moves can also be optimized at register renaming stage. I verified this with perf. Also, GPR zero moves can be optimized too. Thanks @RKSimon for pointing this out.

mattd accepted this revision.Thu, Oct 11, 9:34 AM

This LGTM! I didn't have much to say, your descriptions were clear, and from what I can tell the changes look good.

463 ↗(On Diff #169213)

nit: Add a period to the end of this line.

515 ↗(On Diff #169213)


527 ↗(On Diff #169213)

nit: Add a period to the end of this line.

This revision is now accepted and ready to land.Thu, Oct 11, 9:34 AM
mattd added a comment.Thu, Oct 11, 9:35 AM

I've accepted the patch, but it would be good to get others feedback before landing this.

RKSimon added inline comments.Thu, Oct 11, 10:11 AM
176 ↗(On Diff #169213)

Any reason why we don't reuse the name isOptimizableRegisterMove?

andreadb added inline comments.Thu, Oct 11, 11:32 AM
176 ↗(On Diff #169213)

No reason... I am happy to change the name of that class to "IsOptimizableRegisterMove".

463 ↗(On Diff #169213)

Will do.

515 ↗(On Diff #169213)

Will do.

527 ↗(On Diff #169213)

Will do.

RKSimon accepted this revision.Thu, Oct 11, 11:43 AM

LGTM - apart from 2 different names for the same thing and @mattd's minors

This revision was automatically updated to reflect the committed changes.