[all-commits] [llvm/llvm-project] 1d9291: [MC] Rewrite tablegen for printInstrAlias to comip...
Reid Kleckner via All-commits
all-commits at lists.llvm.org
Fri Dec 6 15:02:36 PST 2019
Branch: refs/heads/master
Home: https://github.com/llvm/llvm-project
Commit: 1d9291cc785c453ac189d131271e91f8aaf6858c
https://github.com/llvm/llvm-project/commit/1d9291cc785c453ac189d131271e91f8aaf6858c
Author: Reid Kleckner <rnk at google.com>
Date: 2019-12-06 (Fri, 06 Dec 2019)
Changed paths:
M llvm/include/llvm/MC/MCInstPrinter.h
M llvm/lib/MC/MCInstPrinter.cpp
M llvm/utils/TableGen/AsmWriterEmitter.cpp
Log Message:
-----------
[MC] Rewrite tablegen for printInstrAlias to comiple faster, NFC
Before this change, the *InstPrinter.cpp files of each target where some
of the slowest objects to compile in all of LLVM. See this snippet produced by
ClangBuildAnalyzer:
https://reviews.llvm.org/P8171$96
Search for "InstPrinter", and see that it shows up in a few places.
Tablegen was emitting a large switch containing a sequence of operand checks,
each of which created many conditions and many BBs. Register allocation and
jump threading both did not scale well with such a large repetitive sequence of
basic blocks.
So, this change essentially turns those control flow structures into
data. The previous structure looked like:
switch (Opc) {
case TGT::ADD:
// check alias 1
if (MI->getOperandCount() == N && // check num opnds
MI->getOperand(0).isReg() && // check opnd 0
...
MI->getOperand(1).isImm() && // check opnd 1
AsmString = "foo";
break;
}
// check alias 2
if (...)
...
return false;
The new structure looks like:
OpToPatterns: Sorted table of opcodes mapping to pattern indices.
\->
Patterns: List of patterns. Previous table points to subrange of
patterns to match.
\->
Conds: The if conditions above encoded as a kind and 32-bit value.
See MCInstPrinter.cpp for the details of how the new data structures are
interpreted.
Here are some before and after metrics.
Time to compile AArch64InstPrinter.cpp:
0m29.062s vs. 0m2.203s
size of the obj:
3.9M vs. 676K
size of clang.exe:
97M vs. 96M
I have not benchmarked disassembly performance, but typically
disassemblers are bottlenecked on IO and string processing, not alias
matching, so I'm not sure it's interesting enough to be worth doing.
Reviewers: RKSimon, andreadb, xbolva00, craig.topper
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D70650
More information about the All-commits
mailing list