llvm-project/mlir/lib/TableGen/Dialect.cpp

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

115 lines
3.4 KiB
C++
Raw Normal View History

//===- Dialect.cpp - Dialect wrapper class --------------------------------===//
//
// 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
//
//===----------------------------------------------------------------------===//
//
// Dialect wrapper to simplify using TableGen Record defining a MLIR dialect.
//
//===----------------------------------------------------------------------===//
#include "mlir/TableGen/Dialect.h"
[mlir][ods] Enable emitting getter/setter prefix Allow emitting get & set prefix for accessors generated for ops. If enabled, then the argument/return/region name gets converted from snake_case to UpperCamel and prefix added. The attribute also allows generating both the current "raw" method along with the prefix'd one to make it easier to stage changes. The option is added on the dialect and currently defaults to existing raw behavior. The expectation is that the staging where both are generated would be short lived and so optimized to keeping the changes local/less invasive (it just generates two functions for each accessor with the same body - most of these internally again call a helper function). But generation can be optimized if needed. I'm unsure about OpAdaptor classes as there it is all get methods (it is a named view into raw data structures), so prefix doesn't add much. This starts with emitting raw-only form (as current behavior) as default, then one can opt-in to raw & prefixed, then just prefixed. The default in OpBase will switch to prefixed-only to be consistent with MLIR style guide. And the option potentially removed later (considered enabling specifying prefix but current discussion more pro keeping it limited and stuck with that). Also add more explicit checking for pruned functions to avoid emitting where no function was added (and so avoiding dereferencing nullptr) during op def/decl generation. See https://bugs.llvm.org/show_bug.cgi?id=51916 for further discussion. Differential Revision: https://reviews.llvm.org/D111033
2021-10-15 06:58:44 +08:00
#include "llvm/TableGen/Error.h"
#include "llvm/TableGen/Record.h"
using namespace mlir;
using namespace mlir::tblgen;
Separate the Registration from Loading dialects in the Context This changes the behavior of constructing MLIRContext to no longer load globally registered dialects on construction. Instead Dialects are only loaded explicitly on demand: - the Parser is lazily loading Dialects in the context as it encounters them during parsing. This is the only purpose for registering dialects and not load them in the context. - Passes are expected to declare the dialects they will create entity from (Operations, Attributes, or Types), and the PassManager is loading Dialects into the Context when starting a pipeline. This changes simplifies the configuration of the registration: a compiler only need to load the dialect for the IR it will emit, and the optimizer is self-contained and load the required Dialects. For example in the Toy tutorial, the compiler only needs to load the Toy dialect in the Context, all the others (linalg, affine, std, LLVM, ...) are automatically loaded depending on the optimization pipeline enabled. To adjust to this change, stop using the existing dialect registration: the global registry will be removed soon. 1) For passes, you need to override the method: virtual void getDependentDialects(DialectRegistry &registry) const {} and registery on the provided registry any dialect that this pass can produce. Passes defined in TableGen can provide this list in the dependentDialects list field. 2) For dialects, on construction you can register dependent dialects using the provided MLIRContext: `context.getOrLoadDialect<DialectName>()` This is useful if a dialect may canonicalize or have interfaces involving another dialect. 3) For loading IR, dialect that can be in the input file must be explicitly registered with the context. `MlirOptMain()` is taking an explicit registry for this purpose. See how the standalone-opt.cpp example is setup: mlir::DialectRegistry registry; registry.insert<mlir::standalone::StandaloneDialect>(); registry.insert<mlir::StandardOpsDialect>(); Only operations from these two dialects can be in the input file. To include all of the dialects in MLIR Core, you can populate the registry this way: mlir::registerAllDialects(registry); 4) For `mlir-translate` callback, as well as frontend, Dialects can be loaded in the context before emitting the IR: context.getOrLoadDialect<ToyDialect>() Differential Revision: https://reviews.llvm.org/D85622
2020-08-19 04:01:19 +08:00
Dialect::Dialect(const llvm::Record *def) : def(def) {
if (def == nullptr)
return;
Separate the Registration from Loading dialects in the Context This changes the behavior of constructing MLIRContext to no longer load globally registered dialects on construction. Instead Dialects are only loaded explicitly on demand: - the Parser is lazily loading Dialects in the context as it encounters them during parsing. This is the only purpose for registering dialects and not load them in the context. - Passes are expected to declare the dialects they will create entity from (Operations, Attributes, or Types), and the PassManager is loading Dialects into the Context when starting a pipeline. This changes simplifies the configuration of the registration: a compiler only need to load the dialect for the IR it will emit, and the optimizer is self-contained and load the required Dialects. For example in the Toy tutorial, the compiler only needs to load the Toy dialect in the Context, all the others (linalg, affine, std, LLVM, ...) are automatically loaded depending on the optimization pipeline enabled. To adjust to this change, stop using the existing dialect registration: the global registry will be removed soon. 1) For passes, you need to override the method: virtual void getDependentDialects(DialectRegistry &registry) const {} and registery on the provided registry any dialect that this pass can produce. Passes defined in TableGen can provide this list in the dependentDialects list field. 2) For dialects, on construction you can register dependent dialects using the provided MLIRContext: `context.getOrLoadDialect<DialectName>()` This is useful if a dialect may canonicalize or have interfaces involving another dialect. 3) For loading IR, dialect that can be in the input file must be explicitly registered with the context. `MlirOptMain()` is taking an explicit registry for this purpose. See how the standalone-opt.cpp example is setup: mlir::DialectRegistry registry; registry.insert<mlir::standalone::StandaloneDialect>(); registry.insert<mlir::StandardOpsDialect>(); Only operations from these two dialects can be in the input file. To include all of the dialects in MLIR Core, you can populate the registry this way: mlir::registerAllDialects(registry); 4) For `mlir-translate` callback, as well as frontend, Dialects can be loaded in the context before emitting the IR: context.getOrLoadDialect<ToyDialect>() Differential Revision: https://reviews.llvm.org/D85622
2020-08-19 04:01:19 +08:00
for (StringRef dialect : def->getValueAsListOfStrings("dependentDialects"))
dependentDialects.push_back(dialect);
}
StringRef Dialect::getName() const { return def->getValueAsString("name"); }
StringRef Dialect::getCppNamespace() const {
return def->getValueAsString("cppNamespace");
}
std::string Dialect::getCppClassName() const {
// Simply use the name and remove any '_' tokens.
std::string cppName = def->getName().str();
2021-10-24 11:41:48 +08:00
llvm::erase_value(cppName, '_');
return cppName;
}
static StringRef getAsStringOrEmpty(const llvm::Record &record,
StringRef fieldName) {
if (auto *valueInit = record.getValueInit(fieldName)) {
if (llvm::isa<llvm::StringInit>(valueInit))
return record.getValueAsString(fieldName);
}
return "";
}
StringRef Dialect::getSummary() const {
return getAsStringOrEmpty(*def, "summary");
}
StringRef Dialect::getDescription() const {
return getAsStringOrEmpty(*def, "description");
}
Separate the Registration from Loading dialects in the Context This changes the behavior of constructing MLIRContext to no longer load globally registered dialects on construction. Instead Dialects are only loaded explicitly on demand: - the Parser is lazily loading Dialects in the context as it encounters them during parsing. This is the only purpose for registering dialects and not load them in the context. - Passes are expected to declare the dialects they will create entity from (Operations, Attributes, or Types), and the PassManager is loading Dialects into the Context when starting a pipeline. This changes simplifies the configuration of the registration: a compiler only need to load the dialect for the IR it will emit, and the optimizer is self-contained and load the required Dialects. For example in the Toy tutorial, the compiler only needs to load the Toy dialect in the Context, all the others (linalg, affine, std, LLVM, ...) are automatically loaded depending on the optimization pipeline enabled. To adjust to this change, stop using the existing dialect registration: the global registry will be removed soon. 1) For passes, you need to override the method: virtual void getDependentDialects(DialectRegistry &registry) const {} and registery on the provided registry any dialect that this pass can produce. Passes defined in TableGen can provide this list in the dependentDialects list field. 2) For dialects, on construction you can register dependent dialects using the provided MLIRContext: `context.getOrLoadDialect<DialectName>()` This is useful if a dialect may canonicalize or have interfaces involving another dialect. 3) For loading IR, dialect that can be in the input file must be explicitly registered with the context. `MlirOptMain()` is taking an explicit registry for this purpose. See how the standalone-opt.cpp example is setup: mlir::DialectRegistry registry; registry.insert<mlir::standalone::StandaloneDialect>(); registry.insert<mlir::StandardOpsDialect>(); Only operations from these two dialects can be in the input file. To include all of the dialects in MLIR Core, you can populate the registry this way: mlir::registerAllDialects(registry); 4) For `mlir-translate` callback, as well as frontend, Dialects can be loaded in the context before emitting the IR: context.getOrLoadDialect<ToyDialect>() Differential Revision: https://reviews.llvm.org/D85622
2020-08-19 04:01:19 +08:00
ArrayRef<StringRef> Dialect::getDependentDialects() const {
return dependentDialects;
}
llvm::Optional<StringRef> Dialect::getExtraClassDeclaration() const {
auto value = def->getValueAsString("extraClassDeclaration");
return value.empty() ? llvm::Optional<StringRef>() : value;
}
bool Dialect::hasCanonicalizer() const {
return def->getValueAsBit("hasCanonicalizer");
}
bool Dialect::hasConstantMaterializer() const {
return def->getValueAsBit("hasConstantMaterializer");
}
bool Dialect::hasNonDefaultDestructor() const {
return def->getValueAsBit("hasNonDefaultDestructor");
}
bool Dialect::hasOperationAttrVerify() const {
return def->getValueAsBit("hasOperationAttrVerify");
}
bool Dialect::hasRegionArgAttrVerify() const {
return def->getValueAsBit("hasRegionArgAttrVerify");
}
bool Dialect::hasRegionResultAttrVerify() const {
return def->getValueAsBit("hasRegionResultAttrVerify");
}
bool Dialect::hasOperationInterfaceFallback() const {
return def->getValueAsBit("hasOperationInterfaceFallback");
}
bool Dialect::useDefaultAttributePrinterParser() const {
return def->getValueAsBit("useDefaultAttributePrinterParser");
}
bool Dialect::useDefaultTypePrinterParser() const {
return def->getValueAsBit("useDefaultTypePrinterParser");
}
[mlir][ods] Enable emitting getter/setter prefix Allow emitting get & set prefix for accessors generated for ops. If enabled, then the argument/return/region name gets converted from snake_case to UpperCamel and prefix added. The attribute also allows generating both the current "raw" method along with the prefix'd one to make it easier to stage changes. The option is added on the dialect and currently defaults to existing raw behavior. The expectation is that the staging where both are generated would be short lived and so optimized to keeping the changes local/less invasive (it just generates two functions for each accessor with the same body - most of these internally again call a helper function). But generation can be optimized if needed. I'm unsure about OpAdaptor classes as there it is all get methods (it is a named view into raw data structures), so prefix doesn't add much. This starts with emitting raw-only form (as current behavior) as default, then one can opt-in to raw & prefixed, then just prefixed. The default in OpBase will switch to prefixed-only to be consistent with MLIR style guide. And the option potentially removed later (considered enabling specifying prefix but current discussion more pro keeping it limited and stuck with that). Also add more explicit checking for pruned functions to avoid emitting where no function was added (and so avoiding dereferencing nullptr) during op def/decl generation. See https://bugs.llvm.org/show_bug.cgi?id=51916 for further discussion. Differential Revision: https://reviews.llvm.org/D111033
2021-10-15 06:58:44 +08:00
Dialect::EmitPrefix Dialect::getEmitAccessorPrefix() const {
int prefix = def->getValueAsInt("emitAccessorPrefix");
if (prefix < 0 || prefix > static_cast<int>(EmitPrefix::Both))
PrintFatalError(def->getLoc(), "Invalid accessor prefix value");
return static_cast<EmitPrefix>(prefix);
}
bool Dialect::operator==(const Dialect &other) const {
return def == other.def;
}
bool Dialect::operator<(const Dialect &other) const {
return getName() < other.getName();
}