[PATCH] D44980: [MC][Tblgen] Allow the definition of processor register files in the scheduling model for llvm-mca
Clement Courbet via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Mon Apr 2 23:44:47 PDT 2018
courbet added a comment.
> 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).
================
Comment at: tools/llvm-mca/Dispatch.cpp:33
+ // means: this register file has an unbounded number of physical registers.
+ addRegisterFile({}, NumRegs);
+ if (!SM.hasExtraProcessorInfo())
----------------
```addRegisterFile({} /*all registers*/, NumRegs);```
(for readability) ?
================
Comment at: utils/TableGen/SubtargetEmitter.cpp:608
+void SubtargetEmitter::EmitExtraProcessorInfo(const CodeGenProcModel &ProcModel,
+ raw_ostream &OS) {
----------------
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
================
Comment at: utils/TableGen/SubtargetEmitter.cpp:638
+ OS << "\n // {Name, #PhysRegs, #CostEntries, IndexToCostTbl}\n";
+ OS << "static const llvm::MCRegisterFileDesc " << ProcModel.ModelName
+ << "RegisterFiles"
----------------
All valid ids in Shed (ProcRes, SchedClass, ...) start at 1. Should we add an extra invalid entry with index 0 here for consistency ?
https://reviews.llvm.org/D44980
More information about the llvm-commits
mailing list