2017-02-11 08:27:28 +08:00
|
|
|
//===- MCInstPrinter.cpp - Convert an MCInst to target assembly syntax ----===//
|
2009-09-14 09:43:38 +08:00
|
|
|
//
|
2019-01-19 16:50:56 +08:00
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
2009-09-14 09:43:38 +08:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2017-06-06 19:49:48 +08:00
|
|
|
#include "llvm/MC/MCInstPrinter.h"
|
2017-02-11 08:27:28 +08:00
|
|
|
#include "llvm/ADT/ArrayRef.h"
|
2010-02-12 06:39:10 +08:00
|
|
|
#include "llvm/ADT/StringRef.h"
|
2012-12-04 00:50:05 +08:00
|
|
|
#include "llvm/MC/MCAsmInfo.h"
|
[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
2019-11-24 03:28:54 +08:00
|
|
|
#include "llvm/MC/MCInst.h"
|
2012-12-04 00:50:05 +08:00
|
|
|
#include "llvm/MC/MCInstrInfo.h"
|
[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
2019-11-24 03:28:54 +08:00
|
|
|
#include "llvm/MC/MCSubtargetInfo.h"
|
2012-02-07 13:05:23 +08:00
|
|
|
#include "llvm/Support/ErrorHandling.h"
|
2012-12-06 02:13:19 +08:00
|
|
|
#include "llvm/Support/Format.h"
|
2011-09-16 02:36:29 +08:00
|
|
|
#include "llvm/Support/raw_ostream.h"
|
2017-02-11 08:27:28 +08:00
|
|
|
#include <cinttypes>
|
|
|
|
#include <cstdint>
|
|
|
|
|
2009-09-14 09:43:38 +08:00
|
|
|
using namespace llvm;
|
|
|
|
|
2015-05-29 02:39:50 +08:00
|
|
|
void llvm::dumpBytes(ArrayRef<uint8_t> bytes, raw_ostream &OS) {
|
|
|
|
static const char hex_rep[] = "0123456789abcdef";
|
2019-04-10 13:31:21 +08:00
|
|
|
bool First = true;
|
2015-05-29 02:39:50 +08:00
|
|
|
for (char i: bytes) {
|
2019-04-10 13:31:21 +08:00
|
|
|
if (First)
|
|
|
|
First = false;
|
|
|
|
else
|
|
|
|
OS << ' ';
|
2015-05-29 02:39:50 +08:00
|
|
|
OS << hex_rep[(i & 0xF0) >> 4];
|
|
|
|
OS << hex_rep[i & 0xF];
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-02-11 08:27:28 +08:00
|
|
|
MCInstPrinter::~MCInstPrinter() = default;
|
2010-02-12 06:39:10 +08:00
|
|
|
|
|
|
|
/// getOpcodeName - Return the name of the specified opcode enum (e.g.
|
|
|
|
/// "MOV32ri") or empty if we can't resolve it.
|
|
|
|
StringRef MCInstPrinter::getOpcodeName(unsigned Opcode) const {
|
2012-04-02 16:32:38 +08:00
|
|
|
return MII.getName(Opcode);
|
2010-02-12 06:39:10 +08:00
|
|
|
}
|
2011-03-06 02:43:32 +08:00
|
|
|
|
2011-06-02 10:34:55 +08:00
|
|
|
void MCInstPrinter::printRegName(raw_ostream &OS, unsigned RegNo) const {
|
2012-02-07 13:05:23 +08:00
|
|
|
llvm_unreachable("Target should implement this");
|
2011-03-06 02:43:32 +08:00
|
|
|
}
|
2011-09-16 02:36:29 +08:00
|
|
|
|
2011-09-16 07:38:46 +08:00
|
|
|
void MCInstPrinter::printAnnotation(raw_ostream &OS, StringRef Annot) {
|
2011-09-21 08:25:23 +08:00
|
|
|
if (!Annot.empty()) {
|
2013-10-02 03:21:24 +08:00
|
|
|
if (CommentStream) {
|
2011-10-05 06:44:48 +08:00
|
|
|
(*CommentStream) << Annot;
|
2013-10-02 03:21:24 +08:00
|
|
|
// By definition (see MCInstPrinter.h), CommentStream must end with
|
|
|
|
// a newline after each comment.
|
|
|
|
if (Annot.back() != '\n')
|
|
|
|
(*CommentStream) << '\n';
|
|
|
|
} else
|
2011-10-05 06:44:48 +08:00
|
|
|
OS << " " << MAI.getCommentString() << " " << Annot;
|
2011-09-21 08:25:23 +08:00
|
|
|
}
|
2011-09-16 02:36:29 +08:00
|
|
|
}
|
2012-10-24 06:52:52 +08:00
|
|
|
|
[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
2019-11-24 03:28:54 +08:00
|
|
|
static bool matchAliasCondition(const MCInst &MI, const MCSubtargetInfo *STI,
|
|
|
|
const MCRegisterInfo &MRI, unsigned &OpIdx,
|
|
|
|
const AliasMatchingData &M,
|
[TableGen] Support combining AssemblerPredicates with ORs
For context, the proposed RISC-V bit manipulation extension has a subset
of instructions which require one of two SubtargetFeatures to be
enabled, 'zbb' or 'zbp', and there is no defined feature which both of
these can imply to use as a constraint either (see comments in D65649).
AssemblerPredicates allow multiple SubtargetFeatures to be declared in
the "AssemblerCondString" field, separated by commas, and this means
that the two features must both be enabled. There is no equivalent to
say that _either_ feature X or feature Y must be enabled, short of
creating a dummy SubtargetFeature for this purpose and having features X
and Y imply the new feature.
To solve the case where X or Y is needed without adding a new feature,
and to better match a typical TableGen style, this replaces the existing
"AssemblerCondString" with a dag "AssemblerCondDag" which represents the
same information. Two operators are defined for use with
AssemblerCondDag, "all_of", which matches the current behaviour, and
"any_of", which adds the new proposed ORing features functionality.
This was originally proposed in the RFC at
http://lists.llvm.org/pipermail/llvm-dev/2020-February/139138.html
Changes to all current backends are mechanical to support the replaced
functionality, and are NFCI.
At this stage, it is illegal to combine features with ands and ors in a
single AssemblerCondDag. I suspect this case is sufficiently rare that
adding more complex changes to support it are unnecessary.
Differential Revision: https://reviews.llvm.org/D74338
2020-03-14 01:13:51 +08:00
|
|
|
const AliasPatternCond &C,
|
|
|
|
bool &OrPredicateResult) {
|
[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
2019-11-24 03:28:54 +08:00
|
|
|
// Feature tests are special, they don't consume operands.
|
|
|
|
if (C.Kind == AliasPatternCond::K_Feature)
|
|
|
|
return STI->getFeatureBits().test(C.Value);
|
|
|
|
if (C.Kind == AliasPatternCond::K_NegFeature)
|
|
|
|
return !STI->getFeatureBits().test(C.Value);
|
[TableGen] Support combining AssemblerPredicates with ORs
For context, the proposed RISC-V bit manipulation extension has a subset
of instructions which require one of two SubtargetFeatures to be
enabled, 'zbb' or 'zbp', and there is no defined feature which both of
these can imply to use as a constraint either (see comments in D65649).
AssemblerPredicates allow multiple SubtargetFeatures to be declared in
the "AssemblerCondString" field, separated by commas, and this means
that the two features must both be enabled. There is no equivalent to
say that _either_ feature X or feature Y must be enabled, short of
creating a dummy SubtargetFeature for this purpose and having features X
and Y imply the new feature.
To solve the case where X or Y is needed without adding a new feature,
and to better match a typical TableGen style, this replaces the existing
"AssemblerCondString" with a dag "AssemblerCondDag" which represents the
same information. Two operators are defined for use with
AssemblerCondDag, "all_of", which matches the current behaviour, and
"any_of", which adds the new proposed ORing features functionality.
This was originally proposed in the RFC at
http://lists.llvm.org/pipermail/llvm-dev/2020-February/139138.html
Changes to all current backends are mechanical to support the replaced
functionality, and are NFCI.
At this stage, it is illegal to combine features with ands and ors in a
single AssemblerCondDag. I suspect this case is sufficiently rare that
adding more complex changes to support it are unnecessary.
Differential Revision: https://reviews.llvm.org/D74338
2020-03-14 01:13:51 +08:00
|
|
|
// For feature tests where just one feature is required in a list, set the
|
|
|
|
// predicate result bit to whether the expression will return true, and only
|
|
|
|
// return the real result at the end of list marker.
|
|
|
|
if (C.Kind == AliasPatternCond::K_OrFeature) {
|
|
|
|
OrPredicateResult |= STI->getFeatureBits().test(C.Value);
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
if (C.Kind == AliasPatternCond::K_OrNegFeature) {
|
|
|
|
OrPredicateResult |= !(STI->getFeatureBits().test(C.Value));
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
if (C.Kind == AliasPatternCond::K_EndOrFeatures) {
|
|
|
|
bool Res = OrPredicateResult;
|
|
|
|
OrPredicateResult = false;
|
|
|
|
return Res;
|
|
|
|
}
|
[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
2019-11-24 03:28:54 +08:00
|
|
|
|
|
|
|
// Get and consume an operand.
|
|
|
|
const MCOperand &Opnd = MI.getOperand(OpIdx);
|
|
|
|
++OpIdx;
|
|
|
|
|
|
|
|
// Check the specific condition for the operand.
|
|
|
|
switch (C.Kind) {
|
|
|
|
case AliasPatternCond::K_Imm:
|
|
|
|
// Operand must be a specific immediate.
|
|
|
|
return Opnd.isImm() && Opnd.getImm() == int32_t(C.Value);
|
|
|
|
case AliasPatternCond::K_Reg:
|
|
|
|
// Operand must be a specific register.
|
|
|
|
return Opnd.isReg() && Opnd.getReg() == C.Value;
|
|
|
|
case AliasPatternCond::K_TiedReg:
|
|
|
|
// Operand must match the register of another operand.
|
|
|
|
return Opnd.isReg() && Opnd.getReg() == MI.getOperand(C.Value).getReg();
|
|
|
|
case AliasPatternCond::K_RegClass:
|
|
|
|
// Operand must be a register in this class. Value is a register class id.
|
|
|
|
return Opnd.isReg() && MRI.getRegClass(C.Value).contains(Opnd.getReg());
|
|
|
|
case AliasPatternCond::K_Custom:
|
|
|
|
// Operand must match some custom criteria.
|
|
|
|
return M.ValidateMCOperand(Opnd, *STI, C.Value);
|
|
|
|
case AliasPatternCond::K_Ignore:
|
|
|
|
// Operand can be anything.
|
|
|
|
return true;
|
|
|
|
case AliasPatternCond::K_Feature:
|
|
|
|
case AliasPatternCond::K_NegFeature:
|
[TableGen] Support combining AssemblerPredicates with ORs
For context, the proposed RISC-V bit manipulation extension has a subset
of instructions which require one of two SubtargetFeatures to be
enabled, 'zbb' or 'zbp', and there is no defined feature which both of
these can imply to use as a constraint either (see comments in D65649).
AssemblerPredicates allow multiple SubtargetFeatures to be declared in
the "AssemblerCondString" field, separated by commas, and this means
that the two features must both be enabled. There is no equivalent to
say that _either_ feature X or feature Y must be enabled, short of
creating a dummy SubtargetFeature for this purpose and having features X
and Y imply the new feature.
To solve the case where X or Y is needed without adding a new feature,
and to better match a typical TableGen style, this replaces the existing
"AssemblerCondString" with a dag "AssemblerCondDag" which represents the
same information. Two operators are defined for use with
AssemblerCondDag, "all_of", which matches the current behaviour, and
"any_of", which adds the new proposed ORing features functionality.
This was originally proposed in the RFC at
http://lists.llvm.org/pipermail/llvm-dev/2020-February/139138.html
Changes to all current backends are mechanical to support the replaced
functionality, and are NFCI.
At this stage, it is illegal to combine features with ands and ors in a
single AssemblerCondDag. I suspect this case is sufficiently rare that
adding more complex changes to support it are unnecessary.
Differential Revision: https://reviews.llvm.org/D74338
2020-03-14 01:13:51 +08:00
|
|
|
case AliasPatternCond::K_OrFeature:
|
|
|
|
case AliasPatternCond::K_OrNegFeature:
|
|
|
|
case AliasPatternCond::K_EndOrFeatures:
|
[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
2019-11-24 03:28:54 +08:00
|
|
|
llvm_unreachable("handled earlier");
|
|
|
|
}
|
|
|
|
llvm_unreachable("invalid kind");
|
|
|
|
}
|
|
|
|
|
|
|
|
const char *MCInstPrinter::matchAliasPatterns(const MCInst *MI,
|
|
|
|
const MCSubtargetInfo *STI,
|
|
|
|
const AliasMatchingData &M) {
|
|
|
|
// Binary search by opcode. Return false if there are no aliases for this
|
|
|
|
// opcode.
|
|
|
|
auto It = lower_bound(M.OpToPatterns, MI->getOpcode(),
|
|
|
|
[](const PatternsForOpcode &L, unsigned Opcode) {
|
|
|
|
return L.Opcode < Opcode;
|
|
|
|
});
|
|
|
|
if (It == M.OpToPatterns.end() || It->Opcode != MI->getOpcode())
|
|
|
|
return nullptr;
|
|
|
|
|
|
|
|
// Try all patterns for this opcode.
|
|
|
|
uint32_t AsmStrOffset = ~0U;
|
|
|
|
ArrayRef<AliasPattern> Patterns =
|
|
|
|
M.Patterns.slice(It->PatternStart, It->NumPatterns);
|
|
|
|
for (const AliasPattern &P : Patterns) {
|
|
|
|
// Check operand count first.
|
|
|
|
if (MI->getNumOperands() != P.NumOperands)
|
|
|
|
return nullptr;
|
|
|
|
|
|
|
|
// Test all conditions for this pattern.
|
|
|
|
ArrayRef<AliasPatternCond> Conds =
|
|
|
|
M.PatternConds.slice(P.AliasCondStart, P.NumConds);
|
|
|
|
unsigned OpIdx = 0;
|
[TableGen] Support combining AssemblerPredicates with ORs
For context, the proposed RISC-V bit manipulation extension has a subset
of instructions which require one of two SubtargetFeatures to be
enabled, 'zbb' or 'zbp', and there is no defined feature which both of
these can imply to use as a constraint either (see comments in D65649).
AssemblerPredicates allow multiple SubtargetFeatures to be declared in
the "AssemblerCondString" field, separated by commas, and this means
that the two features must both be enabled. There is no equivalent to
say that _either_ feature X or feature Y must be enabled, short of
creating a dummy SubtargetFeature for this purpose and having features X
and Y imply the new feature.
To solve the case where X or Y is needed without adding a new feature,
and to better match a typical TableGen style, this replaces the existing
"AssemblerCondString" with a dag "AssemblerCondDag" which represents the
same information. Two operators are defined for use with
AssemblerCondDag, "all_of", which matches the current behaviour, and
"any_of", which adds the new proposed ORing features functionality.
This was originally proposed in the RFC at
http://lists.llvm.org/pipermail/llvm-dev/2020-February/139138.html
Changes to all current backends are mechanical to support the replaced
functionality, and are NFCI.
At this stage, it is illegal to combine features with ands and ors in a
single AssemblerCondDag. I suspect this case is sufficiently rare that
adding more complex changes to support it are unnecessary.
Differential Revision: https://reviews.llvm.org/D74338
2020-03-14 01:13:51 +08:00
|
|
|
bool OrPredicateResult = false;
|
[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
2019-11-24 03:28:54 +08:00
|
|
|
if (llvm::all_of(Conds, [&](const AliasPatternCond &C) {
|
[TableGen] Support combining AssemblerPredicates with ORs
For context, the proposed RISC-V bit manipulation extension has a subset
of instructions which require one of two SubtargetFeatures to be
enabled, 'zbb' or 'zbp', and there is no defined feature which both of
these can imply to use as a constraint either (see comments in D65649).
AssemblerPredicates allow multiple SubtargetFeatures to be declared in
the "AssemblerCondString" field, separated by commas, and this means
that the two features must both be enabled. There is no equivalent to
say that _either_ feature X or feature Y must be enabled, short of
creating a dummy SubtargetFeature for this purpose and having features X
and Y imply the new feature.
To solve the case where X or Y is needed without adding a new feature,
and to better match a typical TableGen style, this replaces the existing
"AssemblerCondString" with a dag "AssemblerCondDag" which represents the
same information. Two operators are defined for use with
AssemblerCondDag, "all_of", which matches the current behaviour, and
"any_of", which adds the new proposed ORing features functionality.
This was originally proposed in the RFC at
http://lists.llvm.org/pipermail/llvm-dev/2020-February/139138.html
Changes to all current backends are mechanical to support the replaced
functionality, and are NFCI.
At this stage, it is illegal to combine features with ands and ors in a
single AssemblerCondDag. I suspect this case is sufficiently rare that
adding more complex changes to support it are unnecessary.
Differential Revision: https://reviews.llvm.org/D74338
2020-03-14 01:13:51 +08:00
|
|
|
return matchAliasCondition(*MI, STI, MRI, OpIdx, M, C,
|
|
|
|
OrPredicateResult);
|
[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
2019-11-24 03:28:54 +08:00
|
|
|
})) {
|
|
|
|
// If all conditions matched, use this asm string.
|
|
|
|
AsmStrOffset = P.AsmStrOffset;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// If no alias matched, don't print an alias.
|
|
|
|
if (AsmStrOffset == ~0U)
|
|
|
|
return nullptr;
|
|
|
|
|
|
|
|
// Go to offset AsmStrOffset and use the null terminated string there. The
|
|
|
|
// offset should point to the beginning of an alias string, so it should
|
|
|
|
// either be zero or be preceded by a null byte.
|
|
|
|
assert(AsmStrOffset < M.AsmStrings.size() &&
|
|
|
|
(AsmStrOffset == 0 || M.AsmStrings[AsmStrOffset - 1] == '\0') &&
|
|
|
|
"bad asm string offset");
|
|
|
|
return M.AsmStrings.data() + AsmStrOffset;
|
|
|
|
}
|
|
|
|
|
2012-10-24 06:52:52 +08:00
|
|
|
/// Utility functions to make adding mark ups simpler.
|
|
|
|
StringRef MCInstPrinter::markup(StringRef s) const {
|
|
|
|
if (getUseMarkup())
|
|
|
|
return s;
|
|
|
|
else
|
|
|
|
return "";
|
|
|
|
}
|
2012-12-06 02:13:19 +08:00
|
|
|
|
2013-08-02 05:18:16 +08:00
|
|
|
// For asm-style hex (e.g. 0ffh) the first digit always has to be a number.
|
|
|
|
static bool needsLeadingZero(uint64_t Value)
|
|
|
|
{
|
2017-02-11 08:27:28 +08:00
|
|
|
while (Value)
|
2013-08-02 05:18:16 +08:00
|
|
|
{
|
|
|
|
uint64_t digit = (Value >> 60) & 0xf;
|
|
|
|
if (digit != 0)
|
|
|
|
return (digit >= 0xa);
|
|
|
|
Value <<= 4;
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2015-02-16 06:15:41 +08:00
|
|
|
format_object<int64_t> MCInstPrinter::formatDec(int64_t Value) const {
|
2013-08-02 05:18:16 +08:00
|
|
|
return format("%" PRId64, Value);
|
|
|
|
}
|
|
|
|
|
2015-02-16 06:15:41 +08:00
|
|
|
format_object<int64_t> MCInstPrinter::formatHex(int64_t Value) const {
|
2019-09-06 09:13:32 +08:00
|
|
|
switch (PrintHexStyle) {
|
2013-08-02 05:18:16 +08:00
|
|
|
case HexStyle::C:
|
2019-09-06 09:13:32 +08:00
|
|
|
if (Value < 0) {
|
|
|
|
if (Value == std::numeric_limits<int64_t>::min())
|
|
|
|
return format<int64_t>("-0x8000000000000000", Value);
|
2013-08-02 05:18:16 +08:00
|
|
|
return format("-0x%" PRIx64, -Value);
|
2019-09-06 09:13:32 +08:00
|
|
|
}
|
|
|
|
return format("0x%" PRIx64, Value);
|
2013-08-02 05:18:16 +08:00
|
|
|
case HexStyle::Asm:
|
|
|
|
if (Value < 0) {
|
2019-09-06 09:13:32 +08:00
|
|
|
if (Value == std::numeric_limits<int64_t>::min())
|
|
|
|
return format<int64_t>("-8000000000000000h", Value);
|
|
|
|
if (needsLeadingZero(-(uint64_t)(Value)))
|
2013-08-02 05:18:16 +08:00
|
|
|
return format("-0%" PRIx64 "h", -Value);
|
2019-09-06 09:13:32 +08:00
|
|
|
return format("-%" PRIx64 "h", -Value);
|
2013-08-02 05:18:16 +08:00
|
|
|
}
|
2019-09-06 09:13:32 +08:00
|
|
|
if (needsLeadingZero((uint64_t)(Value)))
|
|
|
|
return format("0%" PRIx64 "h", Value);
|
|
|
|
return format("%" PRIx64 "h", Value);
|
2013-08-02 05:18:16 +08:00
|
|
|
}
|
2013-08-02 17:37:20 +08:00
|
|
|
llvm_unreachable("unsupported print style");
|
2013-08-02 05:18:16 +08:00
|
|
|
}
|
|
|
|
|
2015-02-16 06:15:41 +08:00
|
|
|
format_object<uint64_t> MCInstPrinter::formatHex(uint64_t Value) const {
|
2013-08-02 05:18:16 +08:00
|
|
|
switch(PrintHexStyle) {
|
|
|
|
case HexStyle::C:
|
|
|
|
return format("0x%" PRIx64, Value);
|
|
|
|
case HexStyle::Asm:
|
|
|
|
if (needsLeadingZero(Value))
|
|
|
|
return format("0%" PRIx64 "h", Value);
|
|
|
|
else
|
|
|
|
return format("%" PRIx64 "h", Value);
|
|
|
|
}
|
2013-08-02 17:37:20 +08:00
|
|
|
llvm_unreachable("unsupported print style");
|
2012-12-06 02:13:19 +08:00
|
|
|
}
|