2016-11-15 17:51:02 +08:00
|
|
|
//===- SubtargetFeatureInfo.cpp - Helpers for subtarget features ----------===//
|
|
|
|
//
|
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
|
2016-11-15 17:51:02 +08:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#include "SubtargetFeatureInfo.h"
|
Check that emitted instructions meet their predicates on all targets except ARM, Mips, and X86.
Summary:
* ARM is omitted from this patch because this check appears to expose bugs in this target.
* Mips is omitted from this patch because this check either detects bugs or deliberate
emission of instructions that don't satisfy their predicates. One deliberate
use is the SYNC instruction where the version with an operand is correctly
defined as requiring MIPS32 while the version without an operand is defined
as an alias of 'SYNC 0' and requires MIPS2.
* X86 is omitted from this patch because it doesn't use the tablegen-erated
MCCodeEmitter infrastructure.
Patches for ARM and Mips will follow.
Depends on D25617
Reviewers: tstellarAMD, jmolloy
Subscribers: wdng, jmolloy, aemerson, rengolin, arsenm, jyknight, nemanjai, nhaehnle, tstellarAMD, llvm-commits
Differential Revision: https://reviews.llvm.org/D25618
llvm-svn: 287439
2016-11-19 21:05:44 +08:00
|
|
|
#include "Types.h"
|
2018-04-30 22:59:11 +08:00
|
|
|
#include "llvm/Config/llvm-config.h"
|
2020-07-20 20:36:27 +08:00
|
|
|
#include "llvm/TableGen/Error.h"
|
2016-11-15 17:51:02 +08:00
|
|
|
#include "llvm/TableGen/Record.h"
|
|
|
|
#include <map>
|
|
|
|
|
|
|
|
using namespace llvm;
|
|
|
|
|
2017-10-15 22:32:27 +08:00
|
|
|
#if !defined(NDEBUG) || defined(LLVM_ENABLE_DUMP)
|
2017-01-28 10:47:46 +08:00
|
|
|
LLVM_DUMP_METHOD void SubtargetFeatureInfo::dump() const {
|
|
|
|
errs() << getEnumName() << " " << Index << "\n" << *TheDef;
|
2016-11-15 17:51:02 +08:00
|
|
|
}
|
2017-01-28 10:47:46 +08:00
|
|
|
#endif
|
2016-11-15 17:51:02 +08:00
|
|
|
|
|
|
|
std::vector<std::pair<Record *, SubtargetFeatureInfo>>
|
|
|
|
SubtargetFeatureInfo::getAll(const RecordKeeper &Records) {
|
|
|
|
std::vector<std::pair<Record *, SubtargetFeatureInfo>> SubtargetFeatures;
|
|
|
|
std::vector<Record *> AllPredicates =
|
|
|
|
Records.getAllDerivedDefinitions("Predicate");
|
|
|
|
for (Record *Pred : AllPredicates) {
|
|
|
|
// Ignore predicates that are not intended for the assembler.
|
|
|
|
//
|
|
|
|
// The "AssemblerMatcherPredicate" string should be promoted to an argument
|
|
|
|
// if we re-use the machinery for non-assembler purposes in future.
|
|
|
|
if (!Pred->getValueAsBit("AssemblerMatcherPredicate"))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (Pred->getName().empty())
|
|
|
|
PrintFatalError(Pred->getLoc(), "Predicate has no name!");
|
|
|
|
|
2019-07-30 23:56:43 +08:00
|
|
|
// Ignore always true predicates.
|
|
|
|
if (Pred->getValueAsString("CondString").empty())
|
|
|
|
continue;
|
|
|
|
|
2016-11-15 17:51:02 +08:00
|
|
|
SubtargetFeatures.emplace_back(
|
|
|
|
Pred, SubtargetFeatureInfo(Pred, SubtargetFeatures.size()));
|
|
|
|
}
|
|
|
|
return SubtargetFeatures;
|
|
|
|
}
|
|
|
|
|
[globalisel][tablegen] Import SelectionDAG's rule predicates and support the equivalent in GIRule.
Summary:
The SelectionDAG importer now imports rules with Predicate's attached via
Requires, PredicateControl, etc. These predicates are implemented as
bitset's to allow multiple predicates to be tested together. However,
unlike the MC layer subtarget features, each target only pays for it's own
predicates (e.g. AArch64 doesn't have 192 feature bits just because X86
needs a lot).
Both AArch64 and X86 derive at least one predicate from the MachineFunction
or Function so they must re-initialize AvailableFeatures before each
function. They also declare locals in <Target>InstructionSelector so that
computeAvailableFeatures() can use the code from SelectionDAG without
modification.
Reviewers: rovka, qcolombet, aditya_nandakumar, t.p.northover, ab
Reviewed By: rovka
Subscribers: aemerson, rengolin, dberris, kristof.beyls, llvm-commits, igorb
Differential Revision: https://reviews.llvm.org/D31418
llvm-svn: 300993
2017-04-21 23:59:56 +08:00
|
|
|
void SubtargetFeatureInfo::emitSubtargetFeatureBitEnumeration(
|
2017-04-30 01:30:09 +08:00
|
|
|
SubtargetFeatureInfoMap &SubtargetFeatures, raw_ostream &OS) {
|
[globalisel][tablegen] Import SelectionDAG's rule predicates and support the equivalent in GIRule.
Summary:
The SelectionDAG importer now imports rules with Predicate's attached via
Requires, PredicateControl, etc. These predicates are implemented as
bitset's to allow multiple predicates to be tested together. However,
unlike the MC layer subtarget features, each target only pays for it's own
predicates (e.g. AArch64 doesn't have 192 feature bits just because X86
needs a lot).
Both AArch64 and X86 derive at least one predicate from the MachineFunction
or Function so they must re-initialize AvailableFeatures before each
function. They also declare locals in <Target>InstructionSelector so that
computeAvailableFeatures() can use the code from SelectionDAG without
modification.
Reviewers: rovka, qcolombet, aditya_nandakumar, t.p.northover, ab
Reviewed By: rovka
Subscribers: aemerson, rengolin, dberris, kristof.beyls, llvm-commits, igorb
Differential Revision: https://reviews.llvm.org/D31418
llvm-svn: 300993
2017-04-21 23:59:56 +08:00
|
|
|
OS << "// Bits for subtarget features that participate in "
|
|
|
|
<< "instruction matching.\n";
|
|
|
|
OS << "enum SubtargetFeatureBits : "
|
|
|
|
<< getMinimalTypeForRange(SubtargetFeatures.size()) << " {\n";
|
|
|
|
for (const auto &SF : SubtargetFeatures) {
|
|
|
|
const SubtargetFeatureInfo &SFI = SF.second;
|
|
|
|
OS << " " << SFI.getEnumBitName() << " = " << SFI.Index << ",\n";
|
|
|
|
}
|
|
|
|
OS << "};\n\n";
|
|
|
|
}
|
|
|
|
|
Check that emitted instructions meet their predicates on all targets except ARM, Mips, and X86.
Summary:
* ARM is omitted from this patch because this check appears to expose bugs in this target.
* Mips is omitted from this patch because this check either detects bugs or deliberate
emission of instructions that don't satisfy their predicates. One deliberate
use is the SYNC instruction where the version with an operand is correctly
defined as requiring MIPS32 while the version without an operand is defined
as an alias of 'SYNC 0' and requires MIPS2.
* X86 is omitted from this patch because it doesn't use the tablegen-erated
MCCodeEmitter infrastructure.
Patches for ARM and Mips will follow.
Depends on D25617
Reviewers: tstellarAMD, jmolloy
Subscribers: wdng, jmolloy, aemerson, rengolin, arsenm, jyknight, nemanjai, nhaehnle, tstellarAMD, llvm-commits
Differential Revision: https://reviews.llvm.org/D25618
llvm-svn: 287439
2016-11-19 21:05:44 +08:00
|
|
|
void SubtargetFeatureInfo::emitNameTable(
|
2017-04-30 01:30:09 +08:00
|
|
|
SubtargetFeatureInfoMap &SubtargetFeatures, raw_ostream &OS) {
|
2017-03-07 05:26:49 +08:00
|
|
|
// Need to sort the name table so that lookup by the log of the enum value
|
|
|
|
// gives the proper name. More specifically, for a feature of value 1<<n,
|
|
|
|
// SubtargetFeatureNames[n] should be the name of the feature.
|
|
|
|
uint64_t IndexUB = 0;
|
|
|
|
for (const auto &SF : SubtargetFeatures)
|
|
|
|
if (IndexUB <= SF.second.Index)
|
|
|
|
IndexUB = SF.second.Index+1;
|
|
|
|
|
|
|
|
std::vector<std::string> Names;
|
|
|
|
if (IndexUB > 0)
|
|
|
|
Names.resize(IndexUB);
|
|
|
|
for (const auto &SF : SubtargetFeatures)
|
|
|
|
Names[SF.second.Index] = SF.second.getEnumName();
|
|
|
|
|
Check that emitted instructions meet their predicates on all targets except ARM, Mips, and X86.
Summary:
* ARM is omitted from this patch because this check appears to expose bugs in this target.
* Mips is omitted from this patch because this check either detects bugs or deliberate
emission of instructions that don't satisfy their predicates. One deliberate
use is the SYNC instruction where the version with an operand is correctly
defined as requiring MIPS32 while the version without an operand is defined
as an alias of 'SYNC 0' and requires MIPS2.
* X86 is omitted from this patch because it doesn't use the tablegen-erated
MCCodeEmitter infrastructure.
Patches for ARM and Mips will follow.
Depends on D25617
Reviewers: tstellarAMD, jmolloy
Subscribers: wdng, jmolloy, aemerson, rengolin, arsenm, jyknight, nemanjai, nhaehnle, tstellarAMD, llvm-commits
Differential Revision: https://reviews.llvm.org/D25618
llvm-svn: 287439
2016-11-19 21:05:44 +08:00
|
|
|
OS << "static const char *SubtargetFeatureNames[] = {\n";
|
2017-03-07 05:26:49 +08:00
|
|
|
for (uint64_t I = 0; I < IndexUB; ++I)
|
|
|
|
OS << " \"" << Names[I] << "\",\n";
|
|
|
|
|
Check that emitted instructions meet their predicates on all targets except ARM, Mips, and X86.
Summary:
* ARM is omitted from this patch because this check appears to expose bugs in this target.
* Mips is omitted from this patch because this check either detects bugs or deliberate
emission of instructions that don't satisfy their predicates. One deliberate
use is the SYNC instruction where the version with an operand is correctly
defined as requiring MIPS32 while the version without an operand is defined
as an alias of 'SYNC 0' and requires MIPS2.
* X86 is omitted from this patch because it doesn't use the tablegen-erated
MCCodeEmitter infrastructure.
Patches for ARM and Mips will follow.
Depends on D25617
Reviewers: tstellarAMD, jmolloy
Subscribers: wdng, jmolloy, aemerson, rengolin, arsenm, jyknight, nemanjai, nhaehnle, tstellarAMD, llvm-commits
Differential Revision: https://reviews.llvm.org/D25618
llvm-svn: 287439
2016-11-19 21:05:44 +08:00
|
|
|
// A small number of targets have no predicates. Null terminate the array to
|
|
|
|
// avoid a zero-length array.
|
|
|
|
OS << " nullptr\n"
|
|
|
|
<< "};\n\n";
|
|
|
|
}
|
|
|
|
|
2016-11-15 17:51:02 +08:00
|
|
|
void SubtargetFeatureInfo::emitComputeAvailableFeatures(
|
Check that emitted instructions meet their predicates on all targets except ARM, Mips, and X86.
Summary:
* ARM is omitted from this patch because this check appears to expose bugs in this target.
* Mips is omitted from this patch because this check either detects bugs or deliberate
emission of instructions that don't satisfy their predicates. One deliberate
use is the SYNC instruction where the version with an operand is correctly
defined as requiring MIPS32 while the version without an operand is defined
as an alias of 'SYNC 0' and requires MIPS2.
* X86 is omitted from this patch because it doesn't use the tablegen-erated
MCCodeEmitter infrastructure.
Patches for ARM and Mips will follow.
Depends on D25617
Reviewers: tstellarAMD, jmolloy
Subscribers: wdng, jmolloy, aemerson, rengolin, arsenm, jyknight, nemanjai, nhaehnle, tstellarAMD, llvm-commits
Differential Revision: https://reviews.llvm.org/D25618
llvm-svn: 287439
2016-11-19 21:05:44 +08:00
|
|
|
StringRef TargetName, StringRef ClassName, StringRef FuncName,
|
2017-04-30 01:30:09 +08:00
|
|
|
SubtargetFeatureInfoMap &SubtargetFeatures, raw_ostream &OS,
|
|
|
|
StringRef ExtraParams) {
|
[globalisel][tablegen] Import SelectionDAG's rule predicates and support the equivalent in GIRule.
Summary:
The SelectionDAG importer now imports rules with Predicate's attached via
Requires, PredicateControl, etc. These predicates are implemented as
bitset's to allow multiple predicates to be tested together. However,
unlike the MC layer subtarget features, each target only pays for it's own
predicates (e.g. AArch64 doesn't have 192 feature bits just because X86
needs a lot).
Both AArch64 and X86 derive at least one predicate from the MachineFunction
or Function so they must re-initialize AvailableFeatures before each
function. They also declare locals in <Target>InstructionSelector so that
computeAvailableFeatures() can use the code from SelectionDAG without
modification.
Reviewers: rovka, qcolombet, aditya_nandakumar, t.p.northover, ab
Reviewed By: rovka
Subscribers: aemerson, rengolin, dberris, kristof.beyls, llvm-commits, igorb
Differential Revision: https://reviews.llvm.org/D31418
llvm-svn: 300993
2017-04-21 23:59:56 +08:00
|
|
|
OS << "PredicateBitset " << TargetName << ClassName << "::\n"
|
2017-04-30 01:30:09 +08:00
|
|
|
<< FuncName << "(const " << TargetName << "Subtarget *Subtarget";
|
|
|
|
if (!ExtraParams.empty())
|
|
|
|
OS << ", " << ExtraParams;
|
|
|
|
OS << ") const {\n";
|
[globalisel][tablegen] Import SelectionDAG's rule predicates and support the equivalent in GIRule.
Summary:
The SelectionDAG importer now imports rules with Predicate's attached via
Requires, PredicateControl, etc. These predicates are implemented as
bitset's to allow multiple predicates to be tested together. However,
unlike the MC layer subtarget features, each target only pays for it's own
predicates (e.g. AArch64 doesn't have 192 feature bits just because X86
needs a lot).
Both AArch64 and X86 derive at least one predicate from the MachineFunction
or Function so they must re-initialize AvailableFeatures before each
function. They also declare locals in <Target>InstructionSelector so that
computeAvailableFeatures() can use the code from SelectionDAG without
modification.
Reviewers: rovka, qcolombet, aditya_nandakumar, t.p.northover, ab
Reviewed By: rovka
Subscribers: aemerson, rengolin, dberris, kristof.beyls, llvm-commits, igorb
Differential Revision: https://reviews.llvm.org/D31418
llvm-svn: 300993
2017-04-21 23:59:56 +08:00
|
|
|
OS << " PredicateBitset Features;\n";
|
|
|
|
for (const auto &SF : SubtargetFeatures) {
|
|
|
|
const SubtargetFeatureInfo &SFI = SF.second;
|
2019-07-30 23:56:43 +08:00
|
|
|
StringRef CondStr = SFI.TheDef->getValueAsString("CondString");
|
|
|
|
assert(!CondStr.empty() && "true predicate should have been filtered");
|
[globalisel][tablegen] Import SelectionDAG's rule predicates and support the equivalent in GIRule.
Summary:
The SelectionDAG importer now imports rules with Predicate's attached via
Requires, PredicateControl, etc. These predicates are implemented as
bitset's to allow multiple predicates to be tested together. However,
unlike the MC layer subtarget features, each target only pays for it's own
predicates (e.g. AArch64 doesn't have 192 feature bits just because X86
needs a lot).
Both AArch64 and X86 derive at least one predicate from the MachineFunction
or Function so they must re-initialize AvailableFeatures before each
function. They also declare locals in <Target>InstructionSelector so that
computeAvailableFeatures() can use the code from SelectionDAG without
modification.
Reviewers: rovka, qcolombet, aditya_nandakumar, t.p.northover, ab
Reviewed By: rovka
Subscribers: aemerson, rengolin, dberris, kristof.beyls, llvm-commits, igorb
Differential Revision: https://reviews.llvm.org/D31418
llvm-svn: 300993
2017-04-21 23:59:56 +08:00
|
|
|
|
2019-07-30 23:56:43 +08:00
|
|
|
OS << " if (" << CondStr << ")\n";
|
2019-08-24 23:02:44 +08:00
|
|
|
OS << " Features.set(" << SFI.getEnumBitName() << ");\n";
|
[globalisel][tablegen] Import SelectionDAG's rule predicates and support the equivalent in GIRule.
Summary:
The SelectionDAG importer now imports rules with Predicate's attached via
Requires, PredicateControl, etc. These predicates are implemented as
bitset's to allow multiple predicates to be tested together. However,
unlike the MC layer subtarget features, each target only pays for it's own
predicates (e.g. AArch64 doesn't have 192 feature bits just because X86
needs a lot).
Both AArch64 and X86 derive at least one predicate from the MachineFunction
or Function so they must re-initialize AvailableFeatures before each
function. They also declare locals in <Target>InstructionSelector so that
computeAvailableFeatures() can use the code from SelectionDAG without
modification.
Reviewers: rovka, qcolombet, aditya_nandakumar, t.p.northover, ab
Reviewed By: rovka
Subscribers: aemerson, rengolin, dberris, kristof.beyls, llvm-commits, igorb
Differential Revision: https://reviews.llvm.org/D31418
llvm-svn: 300993
2017-04-21 23:59:56 +08:00
|
|
|
}
|
|
|
|
OS << " return Features;\n";
|
|
|
|
OS << "}\n\n";
|
|
|
|
}
|
|
|
|
|
|
|
|
void SubtargetFeatureInfo::emitComputeAssemblerAvailableFeatures(
|
|
|
|
StringRef TargetName, StringRef ClassName, StringRef FuncName,
|
2017-04-30 01:30:09 +08:00
|
|
|
SubtargetFeatureInfoMap &SubtargetFeatures, raw_ostream &OS) {
|
2019-03-12 01:04:35 +08:00
|
|
|
OS << "FeatureBitset " << TargetName << ClassName << "::\n"
|
2020-11-06 22:19:59 +08:00
|
|
|
<< FuncName << "(const FeatureBitset &FB) const {\n";
|
2019-03-12 01:04:35 +08:00
|
|
|
OS << " FeatureBitset Features;\n";
|
2016-11-15 17:51:02 +08:00
|
|
|
for (const auto &SF : SubtargetFeatures) {
|
|
|
|
const SubtargetFeatureInfo &SFI = SF.second;
|
|
|
|
|
|
|
|
OS << " if (";
|
|
|
|
|
[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 DagInit *D = SFI.TheDef->getValueAsDag("AssemblerCondDag");
|
|
|
|
std::string CombineType = D->getOperator()->getAsString();
|
|
|
|
if (CombineType != "any_of" && CombineType != "all_of")
|
|
|
|
PrintFatalError(SFI.TheDef->getLoc(), "Invalid AssemblerCondDag!");
|
|
|
|
if (D->getNumArgs() == 0)
|
|
|
|
PrintFatalError(SFI.TheDef->getLoc(), "Invalid AssemblerCondDag!");
|
|
|
|
bool IsOr = CombineType == "any_of";
|
|
|
|
|
|
|
|
if (IsOr)
|
2016-11-15 17:51:02 +08:00
|
|
|
OS << "(";
|
|
|
|
|
2021-03-01 02:59:21 +08:00
|
|
|
ListSeparator LS(IsOr ? " || " : " && ");
|
[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 (auto *Arg : D->getArgs()) {
|
2021-03-01 02:59:21 +08:00
|
|
|
OS << LS;
|
[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
|
|
|
if (auto *NotArg = dyn_cast<DagInit>(Arg)) {
|
|
|
|
if (NotArg->getOperator()->getAsString() != "not" ||
|
|
|
|
NotArg->getNumArgs() != 1)
|
|
|
|
PrintFatalError(SFI.TheDef->getLoc(), "Invalid AssemblerCondDag!");
|
|
|
|
Arg = NotArg->getArg(0);
|
|
|
|
OS << "!";
|
|
|
|
}
|
|
|
|
if (!isa<DefInit>(Arg) ||
|
|
|
|
!cast<DefInit>(Arg)->getDef()->isSubClassOf("SubtargetFeature"))
|
|
|
|
PrintFatalError(SFI.TheDef->getLoc(), "Invalid AssemblerCondDag!");
|
|
|
|
OS << "FB[" << TargetName << "::" << Arg->getAsString() << "]";
|
|
|
|
}
|
|
|
|
|
|
|
|
if (IsOr)
|
|
|
|
OS << ")";
|
2016-11-15 17:51:02 +08:00
|
|
|
|
|
|
|
OS << ")\n";
|
2019-08-24 23:02:44 +08:00
|
|
|
OS << " Features.set(" << SFI.getEnumBitName() << ");\n";
|
2016-11-15 17:51:02 +08:00
|
|
|
}
|
|
|
|
OS << " return Features;\n";
|
|
|
|
OS << "}\n\n";
|
|
|
|
}
|