This is an archive of the discontinued LLVM Phabricator instance.

[MC][Tblgen] Allow the definition of processor register files in the scheduling model for llvm-mca
ClosedPublic

Authored by andreadb on Mar 28 2018, 8:23 AM.

Details

Summary

This patch allows the description of register files in processor scheduling models. This addresses PR36662.

A new tablegen class named 'RegisterFile' has been added to TargetSchedule.td.

Targets can optionally describe register files for their processors using that class.
In particular, class RegisterFile allows to specify:

  • the total number of physical registers.
  • which target registers are accessible through the register file.
  • the cost of allocating a register at register renaming stage.

Example (from this patch - see file X86/X86ScheduleBtVer2.td)

def FpuPRF : RegisterFile<72, [VR64, VR128, VR256], [1, 1, 2]>

Here, FpuPRF describes a register file for MMX/XMM/YMM registers. On Jaguar (btver2), a YMM register definition consumes 2 physical registers, while MMX/XMM register definitions only cost 1 physical register.

The syntax allows to specify an empty set of register classes.
An empty set of register classes means: this register file models all the registers specified by the Target.
For each register class, users can specify an optional register cost. By default, register costs default to 1.
A value of 0 for the number of physical registers means: "this register file has an unbounded number of physical registers".

This patch is structured in two parts. The idea that each part can be committed separatedly.
I left the llvm-mca part here because it was easier to see the impact of the tablegen patch on tests.

Part 1 - MC/Tablegen

A first part adds the tablegen definition of RegisterFile, and teaches the SubtargetEmitter how to emit information related to register files.

Information about register files is accessible through an instance of MCExtraProcessorInfo.
The idea behind this design is to logically partition the processor description which is only used by external tools (like llvm-mca) from the processor information used by the llvm machine schedulers.
I think that this design would make easier for targets to get rid of the extra processor information if they don't want it.

Part 2 - llvm-mca related

The second part of this patch is related to changes to llvm-mca.

The main differences are:

  1. class RegisterFile now needs to take into account the "cost of a register" when allocating physical registers at register renaming stage.
  2. Point 1. triggered a minor refactoring which lef to the removal of the "maximum 32 register files" restriction.
  3. The BackendStatistics view has been updated so that we can print out extra details related to each register file implemented by the processor.

The effect of point 3. is also visible in tests register-files-[1..5].s.

Please let me know what you think.

Thanks,
Andrea

Diff Detail

Repository
rL LLVM

Event Timeline

andreadb created this revision.Mar 28 2018, 8:23 AM

Information about register files is accessible through an instance of MCExtraProcessorInfo.
The idea behind this design is to logically partition the processor description which is only used by external tools (like llvm-mca) from the processor information used by the llvm machine schedulers.
I think that this design would make easier for targets to get rid of the extra processor information if they don't want it.

I like that. We're going to have similar needs with llvm-exegesis (e.g. hardware counters corresponding to resource units).

tools/llvm-mca/Dispatch.cpp
33 ↗(On Diff #140074)
addRegisterFile({} /*all registers*/, NumRegs);

(for readability) ?

utils/TableGen/SubtargetEmitter.cpp
608 ↗(On Diff #140074)

I'm wondering how hard it is to emit this information into a separate file ? As you mentioned in the diff description it would avoid this kind of changes impacting main llvm binaries size/compile time

638 ↗(On Diff #140074)

All valid ids in Shed (ProcRes, SchedClass, ...) start at 1. Should we add an extra invalid entry with index 0 here for consistency ?

andreadb added inline comments.Apr 3 2018, 3:36 AM
tools/llvm-mca/Dispatch.cpp
33 ↗(On Diff #140074)

Yes. If you think it is not needed then I remove it.

utils/TableGen/SubtargetEmitter.cpp
608 ↗(On Diff #140074)

My naive idea was to still keep everything into a single file, and then (maybe as a future patch) have a flag to selectively disable the emission of the extra tables for specific cpus (or entire targets). It is still possible to strip symbols from the binary if we don't want them in the binary.
To be honest, I didn't try to look into having two separate files. I guess, that can be a follow up?

638 ↗(On Diff #140074)

I will do it.

courbet added inline comments.Apr 3 2018, 4:43 AM
utils/TableGen/SubtargetEmitter.cpp
608 ↗(On Diff #140074)

I don't have a strong feeling, but I've seen size of static tables being raised as a concern in previous reviews. This is only a couple hundred bytes, so I guess that's fine.

andreadb added inline comments.Apr 3 2018, 4:55 AM
tools/llvm-mca/Dispatch.cpp
33 ↗(On Diff #140074)

Nevermind... I though I added it. Duh.
I am going to add that comment for readability. Cheers!

andreadb updated this revision to Diff 140760.Apr 3 2018, 5:04 AM

Patch updated.

Addressed review comments from Clement.

Added an invalid register file entry in the tablegen'd table of register file descriptors.

This is what we get on BtVer2 with this patch (in X86GenSubtargetInfo.inc):

// {RegisterClassID, Register Cost}
static const llvm::MCRegisterCostEntry BtVer2ModelRegisterCosts[] = {
  { X86::VR64RegClassID, 1},
  { X86::VR128RegClassID, 1},
  { X86::VR256RegClassID, 2},
  { X86::GR8RegClassID, 1},
  { X86::GR16RegClassID, 1},
  { X86::GR32RegClassID, 1},
  { X86::GR64RegClassID, 1},
  { X86::CCRRegClassID, 1},
};

 // {Name, #PhysRegs, #CostEntries, IndexToCostTbl}
static const llvm::MCRegisterFileDesc BtVer2ModelRegisterFiles[] = {
  { "InvalidRegisterFile", 0, 0, 0 },
  { "FpuPRF", 72, 3, 0},
  { "IntegerPRF", 64, 5, 3},
};

static const llvm::MCExtraProcessorInfo BtVer2ModelExtraInfo = {
  BtVer2ModelRegisterFiles,
  3, // Number of register files.
  BtVer2ModelRegisterCosts,
  8 // Number of register cost entries.
};

A register file with zero physical registers is treated by llvm-mca as an invalid register file. So, entry #0 from the BtVer2ModelRegisterFiles table is never used.

andreadb marked 2 inline comments as done.Apr 3 2018, 5:09 AM
courbet accepted this revision.Apr 3 2018, 5:15 AM
This revision is now accepted and ready to land.Apr 3 2018, 5:15 AM
RKSimon accepted this revision.Apr 3 2018, 5:44 AM

LGTM

This revision was automatically updated to reflect the committed changes.