intel/llvm
1
0
Fork 0
mirror of https://github.com/intel/llvm.git synced 2026-01-20 19:07:53 +08:00
Code Issues Packages Projects Releases Wiki Activity
Files
6785c4f2ff16b4453d1140d9ccbbf00a93d6542e
llvm/mlir/tools/mlir-tblgen/PassGen.cpp

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

483 lines
16 KiB
C++
Raw Normal View History

[mlir][Pass] Add a tablegen backend for defining Pass information This will greatly simplify a number of things related to passes: * Enables generation of pass registration * Enables generation of boiler plate pass utilities * Enables generation of pass documentation This revision focuses on adding the basic structure and adds support for generating the registration for passes in the Transforms/ directory. Future revisions will add more support and move more passes over. Differential Revision: https://reviews.llvm.org/D76656
2020-04-01 01:48:34 -07:00
//===- Pass.cpp - MLIR pass registration generator ------------------------===//
//
// 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
//
//===----------------------------------------------------------------------===//
//
// PassGen uses the description of passes to generate base classes for passes
// and command line registration.
//
//===----------------------------------------------------------------------===//
#include "mlir/TableGen/GenInfo.h"
#include "mlir/TableGen/Pass.h"
#include "llvm/ADT/StringExtras.h"
[mlir][PassIncGen] Refactor how pass registration is generated The current output is a bit clunky and requires including files+macros everywhere, or manually wrapping the file inclusion in a registration function. This revision refactors the pass backend to automatically generate `registerFooPass`/`registerFooPasses` functions that wrap the pass registration. `gen-pass-decls` now takes a `-name` input that specifies a tag name for the group of passes that are being generated. For each pass, the generator now produces a `registerFooPass` where `Foo` is the name of the definition specified in tablegen. It also generates a `registerGroupPasses`, where `Group` is the tag provided via the `-name` input parameter, that registers all of the passes present. Differential Revision: https://reviews.llvm.org/D84983
2020-07-31 13:18:13 -07:00
#include "llvm/Support/CommandLine.h"
[mlir][Pass] Add a tablegen backend for defining Pass information This will greatly simplify a number of things related to passes: * Enables generation of pass registration * Enables generation of boiler plate pass utilities * Enables generation of pass documentation This revision focuses on adding the basic structure and adds support for generating the registration for passes in the Transforms/ directory. Future revisions will add more support and move more passes over. Differential Revision: https://reviews.llvm.org/D76656
2020-04-01 01:48:34 -07:00
#include "llvm/Support/FormatVariadic.h"
#include "llvm/TableGen/Error.h"
#include "llvm/TableGen/Record.h"
using namespace mlir;
using namespace mlir::tblgen;
[NFC][MLIR][TableGen] Eliminate `llvm::` for commonly used types (#110841) Eliminate `llvm::` namespace qualifier for commonly used types in MLIR TableGen backends to reduce code clutter.
2024-10-02 13:23:44 -07:00
using llvm::formatv;
using llvm::RecordKeeper;
[mlir][Pass] Add a tablegen backend for defining Pass information This will greatly simplify a number of things related to passes: * Enables generation of pass registration * Enables generation of boiler plate pass utilities * Enables generation of pass documentation This revision focuses on adding the basic structure and adds support for generating the registration for passes in the Transforms/ directory. Future revisions will add more support and move more passes over. Differential Revision: https://reviews.llvm.org/D76656
2020-04-01 01:48:34 -07:00
[mlir][PassIncGen] Refactor how pass registration is generated The current output is a bit clunky and requires including files+macros everywhere, or manually wrapping the file inclusion in a registration function. This revision refactors the pass backend to automatically generate `registerFooPass`/`registerFooPasses` functions that wrap the pass registration. `gen-pass-decls` now takes a `-name` input that specifies a tag name for the group of passes that are being generated. For each pass, the generator now produces a `registerFooPass` where `Foo` is the name of the definition specified in tablegen. It also generates a `registerGroupPasses`, where `Group` is the tag provided via the `-name` input parameter, that registers all of the passes present. Differential Revision: https://reviews.llvm.org/D84983
2020-07-31 13:18:13 -07:00
static llvm::cl::OptionCategory passGenCat("Options for -gen-pass-decls");
static llvm::cl::opt<std::string>
groupName("name", llvm::cl::desc("The name of this group of passes"),
llvm::cl::cat(passGenCat));
[MLIR] Split autogenerated pass declarations & C++ controllable pass options The pass tablegen backend has been reworked to remove the monolithic nature of the autogenerated declarations. The pass public header can be generated with the -gen-pass-decls option. It contains options structs and registrations: the inclusion of options structs can be controlled individually for each pass by defining the GEN_PASS_DECL_PASSNAME macro; the declaration of the registrations have been kept together and can still be included by defining the GEN_PASS_REGISTRATION macro. The private code used for the pass implementation (i.e. the pass base class and the constructors definitions, if missing from tablegen) can be generated with the -gen-pass-defs option. Similarly to the declarations file, the definitions of each pass can be enabled by defining the GEN_PASS_DEF_PASNAME variable. While doing so, the pass base class has been enriched to also accept a the aformentioned struct of options and copy them to the actual pass options, thus allowing each pass to also be configurable within C++ and not only through command line. Reviewed By: rriddle, mehdi_amini, Mogball, jpienaar Differential Revision: https://reviews.llvm.org/D131839
2022-08-24 09:59:50 +02:00
/// Extract the list of passes from the TableGen records.
[NFC] Rename variable `recordKeeper` to `records` (#110989)
2024-10-03 06:30:31 -07:00
static std::vector<Pass> getPasses(const RecordKeeper &records) {
[MLIR] Split autogenerated pass declarations & C++ controllable pass options The pass tablegen backend has been reworked to remove the monolithic nature of the autogenerated declarations. The pass public header can be generated with the -gen-pass-decls option. It contains options structs and registrations: the inclusion of options structs can be controlled individually for each pass by defining the GEN_PASS_DECL_PASSNAME macro; the declaration of the registrations have been kept together and can still be included by defining the GEN_PASS_REGISTRATION macro. The private code used for the pass implementation (i.e. the pass base class and the constructors definitions, if missing from tablegen) can be generated with the -gen-pass-defs option. Similarly to the declarations file, the definitions of each pass can be enabled by defining the GEN_PASS_DEF_PASNAME variable. While doing so, the pass base class has been enriched to also accept a the aformentioned struct of options and copy them to the actual pass options, thus allowing each pass to also be configurable within C++ and not only through command line. Reviewed By: rriddle, mehdi_amini, Mogball, jpienaar Differential Revision: https://reviews.llvm.org/D131839
2022-08-24 09:59:50 +02:00
std::vector<Pass> passes;
[NFC] Rename variable `recordKeeper` to `records` (#110989)
2024-10-03 06:30:31 -07:00
for (const auto *def : records.getAllDerivedDefinitions("PassBase"))
[MLIR] Split autogenerated pass declarations & C++ controllable pass options The pass tablegen backend has been reworked to remove the monolithic nature of the autogenerated declarations. The pass public header can be generated with the -gen-pass-decls option. It contains options structs and registrations: the inclusion of options structs can be controlled individually for each pass by defining the GEN_PASS_DECL_PASSNAME macro; the declaration of the registrations have been kept together and can still be included by defining the GEN_PASS_REGISTRATION macro. The private code used for the pass implementation (i.e. the pass base class and the constructors definitions, if missing from tablegen) can be generated with the -gen-pass-defs option. Similarly to the declarations file, the definitions of each pass can be enabled by defining the GEN_PASS_DEF_PASNAME variable. While doing so, the pass base class has been enriched to also accept a the aformentioned struct of options and copy them to the actual pass options, thus allowing each pass to also be configurable within C++ and not only through command line. Reviewed By: rriddle, mehdi_amini, Mogball, jpienaar Differential Revision: https://reviews.llvm.org/D131839
2022-08-24 09:59:50 +02:00
passes.emplace_back(def);
return passes;
}
const char *const passHeader = R"(
//===----------------------------------------------------------------------===//
// {0}
//===----------------------------------------------------------------------===//
)";
//===----------------------------------------------------------------------===//
// GEN: Pass registration generation
//===----------------------------------------------------------------------===//
/// The code snippet used to generate a pass registration.
///
/// {0}: The def name of the pass record.
/// {1}: The pass constructor call.
const char *const passRegistrationCode = R"(
//===----------------------------------------------------------------------===//
// {0} Registration
//===----------------------------------------------------------------------===//
inline void register{0}() {{
::mlir::registerPass([]() -> std::unique_ptr<::mlir::Pass> {{
return {1};
});
}
// Old registration code, kept for temporary backwards compatibility.
inline void register{0}Pass() {{
::mlir::registerPass([]() -> std::unique_ptr<::mlir::Pass> {{
return {1};
});
}
)";
/// The code snippet used to generate a function to register all passes in a
/// group.
///
/// {0}: The name of the pass group.
const char *const passGroupRegistrationCode = R"(
//===----------------------------------------------------------------------===//
// {0} Registration
//===----------------------------------------------------------------------===//
inline void register{0}Passes() {{
)";
/// Emits the definition of the struct to be used to control the pass options.
static void emitPassOptionsStruct(const Pass &pass, raw_ostream &os) {
StringRef passName = pass.getDef()->getName();
ArrayRef<PassOption> options = pass.getOptions();
// Emit the struct only if the pass has at least one option.
if (options.empty())
return;
[NFC][MLIR][TableGen] Eliminate `llvm::` for commonly used types (#110841) Eliminate `llvm::` namespace qualifier for commonly used types in MLIR TableGen backends to reduce code clutter.
2024-10-02 13:23:44 -07:00
os << formatv("struct {0}Options {{\n", passName);
[MLIR] Split autogenerated pass declarations & C++ controllable pass options The pass tablegen backend has been reworked to remove the monolithic nature of the autogenerated declarations. The pass public header can be generated with the -gen-pass-decls option. It contains options structs and registrations: the inclusion of options structs can be controlled individually for each pass by defining the GEN_PASS_DECL_PASSNAME macro; the declaration of the registrations have been kept together and can still be included by defining the GEN_PASS_REGISTRATION macro. The private code used for the pass implementation (i.e. the pass base class and the constructors definitions, if missing from tablegen) can be generated with the -gen-pass-defs option. Similarly to the declarations file, the definitions of each pass can be enabled by defining the GEN_PASS_DEF_PASNAME variable. While doing so, the pass base class has been enriched to also accept a the aformentioned struct of options and copy them to the actual pass options, thus allowing each pass to also be configurable within C++ and not only through command line. Reviewed By: rriddle, mehdi_amini, Mogball, jpienaar Differential Revision: https://reviews.llvm.org/D131839
2022-08-24 09:59:50 +02:00
for (const PassOption &opt : options) {
std::string type = opt.getType().str();
if (opt.isListOption())
[mlir] Pass Options ownership modifications (#110582) This change makes two (related) changes: First, it updates the tablegen option for `ListOption` to emit a `SmallVector` instead of an `ArrayRef`. This brings `ListOption` more inline with the traditional `Option`, where values are typically provided using types that have storage. After this change, all options should be fully owned by a Pass' `Options` object after it has been fully constructed, unless the underlying type of the `Option` explicitly indicates otherwise. Second, it updates the generated constructors for Passes to consume options by value instead of reference, and prefers moving options into the pass itself. This should be more efficient for non-trivial options objects, where the previous interface forced a copy to be materialized. Now, at worst case the API materializes a copy (no worse than before); at best-case, all options objects are moved into place. Ideally, we could update the Pass constructor to take an r-value reference to the Options object instead, but this approach will require numerous changes to existing passes and their factory functions. --------- Authored-by: Nikhil Kalra <nkalra@apple.com>
2024-10-01 09:48:51 -07:00
type = "::llvm::SmallVector<" + type + ">";
[MLIR] Split autogenerated pass declarations & C++ controllable pass options The pass tablegen backend has been reworked to remove the monolithic nature of the autogenerated declarations. The pass public header can be generated with the -gen-pass-decls option. It contains options structs and registrations: the inclusion of options structs can be controlled individually for each pass by defining the GEN_PASS_DECL_PASSNAME macro; the declaration of the registrations have been kept together and can still be included by defining the GEN_PASS_REGISTRATION macro. The private code used for the pass implementation (i.e. the pass base class and the constructors definitions, if missing from tablegen) can be generated with the -gen-pass-defs option. Similarly to the declarations file, the definitions of each pass can be enabled by defining the GEN_PASS_DEF_PASNAME variable. While doing so, the pass base class has been enriched to also accept a the aformentioned struct of options and copy them to the actual pass options, thus allowing each pass to also be configurable within C++ and not only through command line. Reviewed By: rriddle, mehdi_amini, Mogball, jpienaar Differential Revision: https://reviews.llvm.org/D131839
2022-08-24 09:59:50 +02:00
[NFC][MLIR][TableGen] Eliminate `llvm::` for commonly used types (#110841) Eliminate `llvm::` namespace qualifier for commonly used types in MLIR TableGen backends to reduce code clutter.
2024-10-02 13:23:44 -07:00
os.indent(2) << formatv("{0} {1}", type, opt.getCppVariableName());
[MLIR] Split autogenerated pass declarations & C++ controllable pass options The pass tablegen backend has been reworked to remove the monolithic nature of the autogenerated declarations. The pass public header can be generated with the -gen-pass-decls option. It contains options structs and registrations: the inclusion of options structs can be controlled individually for each pass by defining the GEN_PASS_DECL_PASSNAME macro; the declaration of the registrations have been kept together and can still be included by defining the GEN_PASS_REGISTRATION macro. The private code used for the pass implementation (i.e. the pass base class and the constructors definitions, if missing from tablegen) can be generated with the -gen-pass-defs option. Similarly to the declarations file, the definitions of each pass can be enabled by defining the GEN_PASS_DEF_PASNAME variable. While doing so, the pass base class has been enriched to also accept a the aformentioned struct of options and copy them to the actual pass options, thus allowing each pass to also be configurable within C++ and not only through command line. Reviewed By: rriddle, mehdi_amini, Mogball, jpienaar Differential Revision: https://reviews.llvm.org/D131839
2022-08-24 09:59:50 +02:00
[TableGen] llvm::Optional => std::optional
2022-12-06 07:21:02 +00:00
if (std::optional<StringRef> defaultVal = opt.getDefaultValue())
[MLIR] Split autogenerated pass declarations & C++ controllable pass options The pass tablegen backend has been reworked to remove the monolithic nature of the autogenerated declarations. The pass public header can be generated with the -gen-pass-decls option. It contains options structs and registrations: the inclusion of options structs can be controlled individually for each pass by defining the GEN_PASS_DECL_PASSNAME macro; the declaration of the registrations have been kept together and can still be included by defining the GEN_PASS_REGISTRATION macro. The private code used for the pass implementation (i.e. the pass base class and the constructors definitions, if missing from tablegen) can be generated with the -gen-pass-defs option. Similarly to the declarations file, the definitions of each pass can be enabled by defining the GEN_PASS_DEF_PASNAME variable. While doing so, the pass base class has been enriched to also accept a the aformentioned struct of options and copy them to the actual pass options, thus allowing each pass to also be configurable within C++ and not only through command line. Reviewed By: rriddle, mehdi_amini, Mogball, jpienaar Differential Revision: https://reviews.llvm.org/D131839
2022-08-24 09:59:50 +02:00
os << " = " << defaultVal;
os << ";\n";
}
os << "};\n";
}
[mlir] Add macro for enabling all generated pass declarations Currently the generated pass declarations have to be enabled per-pass using multiple `GEN_PASS_DECL_{PASSNAME}` defines. This adds `GEN_PASS_DECL`, which enables the declarations for all passes in the group with a single macro. This is convenient for cases where a single header is used for all passes in the group. Reviewed By: mehdi_amini, mscuttari Differential Revision: https://reviews.llvm.org/D134766
2022-09-27 17:23:59 -04:00
static std::string getPassDeclVarName(const Pass &pass) {
return "GEN_PASS_DECL_" + pass.getDef()->getName().upper();
}
[MLIR] Split autogenerated pass declarations & C++ controllable pass options The pass tablegen backend has been reworked to remove the monolithic nature of the autogenerated declarations. The pass public header can be generated with the -gen-pass-decls option. It contains options structs and registrations: the inclusion of options structs can be controlled individually for each pass by defining the GEN_PASS_DECL_PASSNAME macro; the declaration of the registrations have been kept together and can still be included by defining the GEN_PASS_REGISTRATION macro. The private code used for the pass implementation (i.e. the pass base class and the constructors definitions, if missing from tablegen) can be generated with the -gen-pass-defs option. Similarly to the declarations file, the definitions of each pass can be enabled by defining the GEN_PASS_DEF_PASNAME variable. While doing so, the pass base class has been enriched to also accept a the aformentioned struct of options and copy them to the actual pass options, thus allowing each pass to also be configurable within C++ and not only through command line. Reviewed By: rriddle, mehdi_amini, Mogball, jpienaar Differential Revision: https://reviews.llvm.org/D131839
2022-08-24 09:59:50 +02:00
/// Emit the code to be included in the public header of the pass.
static void emitPassDecls(const Pass &pass, raw_ostream &os) {
StringRef passName = pass.getDef()->getName();
[mlir] Add macro for enabling all generated pass declarations Currently the generated pass declarations have to be enabled per-pass using multiple `GEN_PASS_DECL_{PASSNAME}` defines. This adds `GEN_PASS_DECL`, which enables the declarations for all passes in the group with a single macro. This is convenient for cases where a single header is used for all passes in the group. Reviewed By: mehdi_amini, mscuttari Differential Revision: https://reviews.llvm.org/D134766
2022-09-27 17:23:59 -04:00
std::string enableVarName = getPassDeclVarName(pass);
[MLIR] Split autogenerated pass declarations & C++ controllable pass options The pass tablegen backend has been reworked to remove the monolithic nature of the autogenerated declarations. The pass public header can be generated with the -gen-pass-decls option. It contains options structs and registrations: the inclusion of options structs can be controlled individually for each pass by defining the GEN_PASS_DECL_PASSNAME macro; the declaration of the registrations have been kept together and can still be included by defining the GEN_PASS_REGISTRATION macro. The private code used for the pass implementation (i.e. the pass base class and the constructors definitions, if missing from tablegen) can be generated with the -gen-pass-defs option. Similarly to the declarations file, the definitions of each pass can be enabled by defining the GEN_PASS_DEF_PASNAME variable. While doing so, the pass base class has been enriched to also accept a the aformentioned struct of options and copy them to the actual pass options, thus allowing each pass to also be configurable within C++ and not only through command line. Reviewed By: rriddle, mehdi_amini, Mogball, jpienaar Differential Revision: https://reviews.llvm.org/D131839
2022-08-24 09:59:50 +02:00
os << "#ifdef " << enableVarName << "\n";
emitPassOptionsStruct(pass, os);
if (StringRef constructor = pass.getConstructor(); constructor.empty()) {
// Default constructor declaration.
os << "std::unique_ptr<::mlir::Pass> create" << passName << "();\n";
// Declaration of the constructor with options.
if (ArrayRef<PassOption> options = pass.getOptions(); !options.empty())
[NFC][MLIR][TableGen] Eliminate `llvm::` for commonly used types (#110841) Eliminate `llvm::` namespace qualifier for commonly used types in MLIR TableGen backends to reduce code clutter.
2024-10-02 13:23:44 -07:00
os << formatv("std::unique_ptr<::mlir::Pass> create{0}("
"{0}Options options);\n",
passName);
[MLIR] Split autogenerated pass declarations & C++ controllable pass options The pass tablegen backend has been reworked to remove the monolithic nature of the autogenerated declarations. The pass public header can be generated with the -gen-pass-decls option. It contains options structs and registrations: the inclusion of options structs can be controlled individually for each pass by defining the GEN_PASS_DECL_PASSNAME macro; the declaration of the registrations have been kept together and can still be included by defining the GEN_PASS_REGISTRATION macro. The private code used for the pass implementation (i.e. the pass base class and the constructors definitions, if missing from tablegen) can be generated with the -gen-pass-defs option. Similarly to the declarations file, the definitions of each pass can be enabled by defining the GEN_PASS_DEF_PASNAME variable. While doing so, the pass base class has been enriched to also accept a the aformentioned struct of options and copy them to the actual pass options, thus allowing each pass to also be configurable within C++ and not only through command line. Reviewed By: rriddle, mehdi_amini, Mogball, jpienaar Differential Revision: https://reviews.llvm.org/D131839
2022-08-24 09:59:50 +02:00
}
os << "#undef " << enableVarName << "\n";
os << "#endif // " << enableVarName << "\n";
}
/// Emit the code for registering each of the given passes with the global
/// PassRegistry.
static void emitRegistrations(llvm::ArrayRef<Pass> passes, raw_ostream &os) {
os << "#ifdef GEN_PASS_REGISTRATION\n";
for (const Pass &pass : passes) {
std::string constructorCall;
if (StringRef constructor = pass.getConstructor(); !constructor.empty())
constructorCall = constructor.str();
else
[NFC][MLIR][TableGen] Eliminate `llvm::` for commonly used types (#110841) Eliminate `llvm::` namespace qualifier for commonly used types in MLIR TableGen backends to reduce code clutter.
2024-10-02 13:23:44 -07:00
constructorCall = formatv("create{0}()", pass.getDef()->getName()).str();
[MLIR] Split autogenerated pass declarations & C++ controllable pass options The pass tablegen backend has been reworked to remove the monolithic nature of the autogenerated declarations. The pass public header can be generated with the -gen-pass-decls option. It contains options structs and registrations: the inclusion of options structs can be controlled individually for each pass by defining the GEN_PASS_DECL_PASSNAME macro; the declaration of the registrations have been kept together and can still be included by defining the GEN_PASS_REGISTRATION macro. The private code used for the pass implementation (i.e. the pass base class and the constructors definitions, if missing from tablegen) can be generated with the -gen-pass-defs option. Similarly to the declarations file, the definitions of each pass can be enabled by defining the GEN_PASS_DEF_PASNAME variable. While doing so, the pass base class has been enriched to also accept a the aformentioned struct of options and copy them to the actual pass options, thus allowing each pass to also be configurable within C++ and not only through command line. Reviewed By: rriddle, mehdi_amini, Mogball, jpienaar Differential Revision: https://reviews.llvm.org/D131839
2022-08-24 09:59:50 +02:00
[NFC][MLIR][TableGen] Eliminate `llvm::` for commonly used types (#110841) Eliminate `llvm::` namespace qualifier for commonly used types in MLIR TableGen backends to reduce code clutter.
2024-10-02 13:23:44 -07:00
os << formatv(passRegistrationCode, pass.getDef()->getName(),
constructorCall);
[MLIR] Split autogenerated pass declarations & C++ controllable pass options The pass tablegen backend has been reworked to remove the monolithic nature of the autogenerated declarations. The pass public header can be generated with the -gen-pass-decls option. It contains options structs and registrations: the inclusion of options structs can be controlled individually for each pass by defining the GEN_PASS_DECL_PASSNAME macro; the declaration of the registrations have been kept together and can still be included by defining the GEN_PASS_REGISTRATION macro. The private code used for the pass implementation (i.e. the pass base class and the constructors definitions, if missing from tablegen) can be generated with the -gen-pass-defs option. Similarly to the declarations file, the definitions of each pass can be enabled by defining the GEN_PASS_DEF_PASNAME variable. While doing so, the pass base class has been enriched to also accept a the aformentioned struct of options and copy them to the actual pass options, thus allowing each pass to also be configurable within C++ and not only through command line. Reviewed By: rriddle, mehdi_amini, Mogball, jpienaar Differential Revision: https://reviews.llvm.org/D131839
2022-08-24 09:59:50 +02:00
}
[NFC][MLIR][TableGen] Eliminate `llvm::` for commonly used types (#110841) Eliminate `llvm::` namespace qualifier for commonly used types in MLIR TableGen backends to reduce code clutter.
2024-10-02 13:23:44 -07:00
os << formatv(passGroupRegistrationCode, groupName);
[MLIR] Split autogenerated pass declarations & C++ controllable pass options The pass tablegen backend has been reworked to remove the monolithic nature of the autogenerated declarations. The pass public header can be generated with the -gen-pass-decls option. It contains options structs and registrations: the inclusion of options structs can be controlled individually for each pass by defining the GEN_PASS_DECL_PASSNAME macro; the declaration of the registrations have been kept together and can still be included by defining the GEN_PASS_REGISTRATION macro. The private code used for the pass implementation (i.e. the pass base class and the constructors definitions, if missing from tablegen) can be generated with the -gen-pass-defs option. Similarly to the declarations file, the definitions of each pass can be enabled by defining the GEN_PASS_DEF_PASNAME variable. While doing so, the pass base class has been enriched to also accept a the aformentioned struct of options and copy them to the actual pass options, thus allowing each pass to also be configurable within C++ and not only through command line. Reviewed By: rriddle, mehdi_amini, Mogball, jpienaar Differential Revision: https://reviews.llvm.org/D131839
2022-08-24 09:59:50 +02:00
for (const Pass &pass : passes)
os << " register" << pass.getDef()->getName() << "();\n";
os << "}\n";
os << "#undef GEN_PASS_REGISTRATION\n";
os << "#endif // GEN_PASS_REGISTRATION\n";
}
[mlir][Pass] Add support for generating pass utilities via tablegen This revision adds support for generating utilities for passes such as options/statistics/etc. that can be inferred from the tablegen definition. This removes additional boilerplate from the pass, and also makes it easier to remove the reliance on the pass registry to provide certain things(e.g. the pass argument). Differential Revision: https://reviews.llvm.org/D76659
2020-04-01 01:50:29 -07:00
//===----------------------------------------------------------------------===//
// GEN: Pass base class generation
//===----------------------------------------------------------------------===//
/// The code snippet used to generate the start of a pass base class.
///
/// {0}: The def name of the pass record.
[mlir][Pass] Update the PassGen to generate base classes instead of utilities Summary: This is much cleaner, and fits the same structure as many other tablegen backends. This was not done originally as the CRTP in the pass classes made it overly verbose/complex. Differential Revision: https://reviews.llvm.org/D77367
2020-04-07 13:58:12 -07:00
/// {1}: The base class for the pass.
/// {2): The command line argument for the pass.
[mlir] Reformat whitespace in dependent dialects codegen (#78090) The generated code for dependent dialects is awkwardly formatted, making the code harder to read. This change reformats the whitespace to align code in its context and avoid unnecessary empty lines. Also included are some typo fixes. Below are examples of the codegen for a dialect before and after the change. Before: ``` GPUDialect::GPUDialect(::mlir::MLIRContext *context) : ::mlir::Dialect(getDialectNamespace(), context, ::mlir::TypeID::get<GPUDialect>()) { getContext()->loadDialect<arith::ArithDialect>(); initialize(); } ``` After: ``` GPUDialect::GPUDialect(::mlir::MLIRContext *context) : ::mlir::Dialect(getDialectNamespace(), context, ::mlir::TypeID::get<GPUDialect>()) { getContext()->loadDialect<arith::ArithDialect>(); initialize(); } ``` Below are examples of the codegen for a pass before and after the change. Before: ``` /// Return the dialect that must be loaded in the context before this pass. void getDependentDialects(::mlir::DialectRegistry &registry) const override { registry.insert<func::FuncDialect>(); registry.insert<tensor::TensorDialect>(); registry.insert<tosa::TosaDialect>(); } ``` After: ``` /// Register the dialects that must be loaded in the context before this pass. void getDependentDialects(::mlir::DialectRegistry &registry) const override { registry.insert<func::FuncDialect>(); registry.insert<tensor::TensorDialect>(); registry.insert<tosa::TosaDialect>(); } ```
2024-01-15 02:11:52 -08:00
/// {3}: The summary for the pass.
/// {4}: The dependent dialects registration.
[MLIR] Fix autogenerated pass constructors linkage The patch addresses the linkage of the new autogenerated pass constructors, which, being declared as friend functions, resulted in having an inline nature and thus their implementations not being exported. Reviewd By: mehdi_amini, rriddle Differential Revision: https://reviews.llvm.org/D132572
2022-08-29 10:57:58 +02:00
const char *const baseClassBegin = R"(
[mlir][Pass] Update the PassGen to generate base classes instead of utilities Summary: This is much cleaner, and fits the same structure as many other tablegen backends. This was not done originally as the CRTP in the pass classes made it overly verbose/complex. Differential Revision: https://reviews.llvm.org/D77367
2020-04-07 13:58:12 -07:00
template <typename DerivedT>
class {0}Base : public {1} {
public:
[mlir][ODS] Use StringLiteral instead of StringRef when applicable Use `StringLiteral` for function return type if it is known to return constant string literals only. This will make it visible to API users, that such values can be safely stored, since they refers to constant data, which will never be deallocated. `StringRef` is general is not safe to store for a long term, since it might refer to temporal data allocated in heap. Add `inline` and `constexpr` methods support to `OpMethod`. Reviewed By: mehdi_amini Differential Revision: https://reviews.llvm.org/D97390
2021-02-04 17:12:15 +00:00
using Base = {0}Base;
[mlir][NFC] Refactor ClassID into a TypeID class. Summary: ClassID is a bit janky right now as it involves passing a magic pointer around. This revision hides the internal implementation mechanism within a new class TypeID. This class is a value-typed wrapper around the original ClassID implementation. Differential Revision: https://reviews.llvm.org/D77768
2020-04-10 23:46:52 -07:00
{0}Base() : {1}(::mlir::TypeID::get<DerivedT>()) {{}
[mlir][ODS] Fix copy ctor for generate Pass classes Redirect the copy ctor to the actual class instead of overwriting it with `TypeID` based ctor. This allows the final Pass classes to have extra fields and logic for their copy. Reviewed By: lattner Differential Revision: https://reviews.llvm.org/D104302
2021-06-15 18:09:31 +03:00
{0}Base(const {0}Base &other) : {1}(other) {{}
[mlir][NFC] Apply rule of five to *Pass classes (#80998) Define all special member functions for mlir::Pass, mlir::OperationPass, mlir::PassWrapper and PassGen types since these classes explicitly specify copy-ctor. This, subsequently, should silence static analysis checkers that report rule-of-3 / rule-of-5 violations. Given the nature of the types, however, mark other special member functions deleted: the semantics of a Pass type object seems to be that it is only ever created by being wrapped in a smart pointer, so the special member functions are never to be used externally (except for the copy-ctor - it is "special" since it is a "delegating" ctor for derived pass types to use during cloning - see https://reviews.llvm.org/D104302 for details). Deleting other member functions means that `Pass x(std::move(y))` - that used to silently work (via copy-ctor) - would fail to compile now. Yet, as the copy ctors through the hierarchy are under 'protected' access, the issue is unlikely to appear in practice. Co-authored-by: Asya Pronina <anastasiya.pronina@intel.com> Co-authored-by: Harald Rotuna <harald.razvan.rotuna@intel.com>
2024-03-05 09:07:43 +02:00
{0}Base& operator=(const {0}Base &) = delete;
{0}Base({0}Base &&) = delete;
{0}Base& operator=({0}Base &&) = delete;
~{0}Base() = default;
[mlir][Pass] Update the PassGen to generate base classes instead of utilities Summary: This is much cleaner, and fits the same structure as many other tablegen backends. This was not done originally as the CRTP in the pass classes made it overly verbose/complex. Differential Revision: https://reviews.llvm.org/D77367
2020-04-07 13:58:12 -07:00
[mlir][Pass] Add support for generating pass utilities via tablegen This revision adds support for generating utilities for passes such as options/statistics/etc. that can be inferred from the tablegen definition. This removes additional boilerplate from the pass, and also makes it easier to remove the reliance on the pass registry to provide certain things(e.g. the pass argument). Differential Revision: https://reviews.llvm.org/D76659
2020-04-01 01:50:29 -07:00
/// Returns the command-line argument attached to this pass.
[mlir][ODS] Use StringLiteral instead of StringRef when applicable Use `StringLiteral` for function return type if it is known to return constant string literals only. This will make it visible to API users, that such values can be safely stored, since they refers to constant data, which will never be deallocated. `StringRef` is general is not safe to store for a long term, since it might refer to temporal data allocated in heap. Add `inline` and `constexpr` methods support to `OpMethod`. Reviewed By: mehdi_amini Differential Revision: https://reviews.llvm.org/D97390
2021-02-04 17:12:15 +00:00
static constexpr ::llvm::StringLiteral getArgumentName() {
return ::llvm::StringLiteral("{2}");
}
[mlir-tblgen] Use fully qualified names in generated code files Using fully qualified names wherever possible avoids ambiguous class and function names. This is a follow-up to D82371. Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D82471
2020-06-26 13:20:44 +02:00
::llvm::StringRef getArgument() const override { return "{2}"; }
[mlir][Pass] Add support for generating pass utilities via tablegen This revision adds support for generating utilities for passes such as options/statistics/etc. that can be inferred from the tablegen definition. This removes additional boilerplate from the pass, and also makes it easier to remove the reliance on the pass registry to provide certain things(e.g. the pass argument). Differential Revision: https://reviews.llvm.org/D76659
2020-04-01 01:50:29 -07:00
[mlir][tblgen] Avoid compilation failure (#161545) This would have failed during compilation post generation later, trim and use raw string literals to avoid such failures. Probably a few more places where similar failures could occur, but this was unexpected failure user ran into.
2025-10-13 05:55:32 +02:00
::llvm::StringRef getDescription() const override { return R"PD({3})PD"; }
Decouple registring passes from specifying argument/description This patch changes the (not recommended) static registration API from: static PassRegistration<MyPass> reg("my-pass", "My Pass Description."); to: static PassRegistration<MyPass> reg; And the explicit registration from: void registerPass("my-pass", "My Pass Description.", [] { return createMyPass(); }); To: void registerPass([] { return createMyPass(); }); It is expected that Pass implementations overrides the getArgument() method instead. This will ensure that pipeline description can be printed and parsed back. Differential Revision: https://reviews.llvm.org/D104421
2021-06-16 23:41:23 +00:00
[mlir][Pass] Update the PassGen to generate base classes instead of utilities Summary: This is much cleaner, and fits the same structure as many other tablegen backends. This was not done originally as the CRTP in the pass classes made it overly verbose/complex. Differential Revision: https://reviews.llvm.org/D77367
2020-04-07 13:58:12 -07:00
/// Returns the derived pass name.
[mlir][ODS] Use StringLiteral instead of StringRef when applicable Use `StringLiteral` for function return type if it is known to return constant string literals only. This will make it visible to API users, that such values can be safely stored, since they refers to constant data, which will never be deallocated. `StringRef` is general is not safe to store for a long term, since it might refer to temporal data allocated in heap. Add `inline` and `constexpr` methods support to `OpMethod`. Reviewed By: mehdi_amini Differential Revision: https://reviews.llvm.org/D97390
2021-02-04 17:12:15 +00:00
static constexpr ::llvm::StringLiteral getPassName() {
return ::llvm::StringLiteral("{0}");
}
[mlir-tblgen] Use fully qualified names in generated code files Using fully qualified names wherever possible avoids ambiguous class and function names. This is a follow-up to D82371. Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D82471
2020-06-26 13:20:44 +02:00
::llvm::StringRef getName() const override { return "{0}"; }
[mlir][Pass] Update the PassGen to generate base classes instead of utilities Summary: This is much cleaner, and fits the same structure as many other tablegen backends. This was not done originally as the CRTP in the pass classes made it overly verbose/complex. Differential Revision: https://reviews.llvm.org/D77367
2020-04-07 13:58:12 -07:00
/// Support isa/dyn_cast functionality for the derived pass class.
static bool classof(const ::mlir::Pass *pass) {{
[mlir][NFC] Refactor ClassID into a TypeID class. Summary: ClassID is a bit janky right now as it involves passing a magic pointer around. This revision hides the internal implementation mechanism within a new class TypeID. This class is a value-typed wrapper around the original ClassID implementation. Differential Revision: https://reviews.llvm.org/D77768
2020-04-10 23:46:52 -07:00
return pass->getTypeID() == ::mlir::TypeID::get<DerivedT>();
[mlir][Pass] Update the PassGen to generate base classes instead of utilities Summary: This is much cleaner, and fits the same structure as many other tablegen backends. This was not done originally as the CRTP in the pass classes made it overly verbose/complex. Differential Revision: https://reviews.llvm.org/D77367
2020-04-07 13:58:12 -07:00
}
/// A clone method to create a copy of this pass.
[mlir] Avoid pontentially ambiguous class name Summary: The Pass class exists in both the mlir and the llvm namespaces. Use the fully qualified class name to avoid any ambiguities. Reviewers: rriddle Reviewed By: rriddle Subscribers: mehdi_amini, jpienaar, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, aartbik, liufengdb, stephenneuendorffer, Joonsoo, grosul1, jurahul, msifontes Tags: #mlir Differential Revision: https://reviews.llvm.org/D82371
2020-06-23 21:24:04 +02:00
std::unique_ptr<::mlir::Pass> clonePass() const override {{
[mlir][Pass] Update the PassGen to generate base classes instead of utilities Summary: This is much cleaner, and fits the same structure as many other tablegen backends. This was not done originally as the CRTP in the pass classes made it overly verbose/complex. Differential Revision: https://reviews.llvm.org/D77367
2020-04-07 13:58:12 -07:00
return std::make_unique<DerivedT>(*static_cast<const DerivedT *>(this));
}
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-18 20:01:19 +00:00
/// Return the dialect that must be loaded in the context before this pass.
void getDependentDialects(::mlir::DialectRegistry &registry) const override {
Decouple registring passes from specifying argument/description This patch changes the (not recommended) static registration API from: static PassRegistration<MyPass> reg("my-pass", "My Pass Description."); to: static PassRegistration<MyPass> reg; And the explicit registration from: void registerPass("my-pass", "My Pass Description.", [] { return createMyPass(); }); To: void registerPass([] { return createMyPass(); }); It is expected that Pass implementations overrides the getArgument() method instead. This will ensure that pipeline description can be printed and parsed back. Differential Revision: https://reviews.llvm.org/D104421
2021-06-16 23:41:23 +00:00
{4}
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-18 20:01:19 +00:00
}
[mlir] Rework the implementation of TypeID This commit restructures how TypeID is implemented to ideally avoid the current problems related to shared libraries. This is done by changing the "implicit" fallback path to use the name of the type, instead of using a static template variable (which breaks shared libraries). The major downside to this is that it adds some additional initialization costs for the implicit path. Given the use of type names for uniqueness in the fallback, we also no longer allow types defined in anonymous namespaces to have an implicit TypeID. To simplify defining an ID for these classes, a new `MLIR_DEFINE_EXPLICIT_INTERNAL_INLINE_TYPE_ID` macro was added to allow for explicitly defining a TypeID directly on an internal class. To help identify when types are using the fallback, `-debug-only=typeid` can be used to log which types are using implicit ids. This change generally only requires changes to the test passes, which are all defined in anonymous namespaces, and thus can't use the fallback any longer. Differential Revision: https://reviews.llvm.org/D122775
2022-03-30 17:00:37 -07:00
/// Explicitly declare the TypeID for this class. We declare an explicit private
/// instantiation because Pass classes should only be visible by the current
/// library.
MLIR_DEFINE_EXPLICIT_INTERNAL_INLINE_TYPE_ID({0}Base<DerivedT>)
[mlir][Pass] Add support for generating pass utilities via tablegen This revision adds support for generating utilities for passes such as options/statistics/etc. that can be inferred from the tablegen definition. This removes additional boilerplate from the pass, and also makes it easier to remove the reliance on the pass registry to provide certain things(e.g. the pass argument). Differential Revision: https://reviews.llvm.org/D76659
2020-04-01 01:50:29 -07:00
)";
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-18 20:01:19 +00:00
/// Registration for a single dependent dialect, to be inserted for each
/// dependent dialect in the `getDependentDialects` above.
[mlir] Reformat whitespace in dependent dialects codegen (#78090) The generated code for dependent dialects is awkwardly formatted, making the code harder to read. This change reformats the whitespace to align code in its context and avoid unnecessary empty lines. Also included are some typo fixes. Below are examples of the codegen for a dialect before and after the change. Before: ``` GPUDialect::GPUDialect(::mlir::MLIRContext *context) : ::mlir::Dialect(getDialectNamespace(), context, ::mlir::TypeID::get<GPUDialect>()) { getContext()->loadDialect<arith::ArithDialect>(); initialize(); } ``` After: ``` GPUDialect::GPUDialect(::mlir::MLIRContext *context) : ::mlir::Dialect(getDialectNamespace(), context, ::mlir::TypeID::get<GPUDialect>()) { getContext()->loadDialect<arith::ArithDialect>(); initialize(); } ``` Below are examples of the codegen for a pass before and after the change. Before: ``` /// Return the dialect that must be loaded in the context before this pass. void getDependentDialects(::mlir::DialectRegistry &registry) const override { registry.insert<func::FuncDialect>(); registry.insert<tensor::TensorDialect>(); registry.insert<tosa::TosaDialect>(); } ``` After: ``` /// Register the dialects that must be loaded in the context before this pass. void getDependentDialects(::mlir::DialectRegistry &registry) const override { registry.insert<func::FuncDialect>(); registry.insert<tensor::TensorDialect>(); registry.insert<tosa::TosaDialect>(); } ```
2024-01-15 02:11:52 -08:00
const char *const dialectRegistrationTemplate = "registry.insert<{0}>();";
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-18 20:01:19 +00:00
[MLIR] Fix autogenerated pass constructors linkage The patch addresses the linkage of the new autogenerated pass constructors, which, being declared as friend functions, resulted in having an inline nature and thus their implementations not being exported. Reviewd By: mehdi_amini, rriddle Differential Revision: https://reviews.llvm.org/D132572
2022-08-29 10:57:58 +02:00
const char *const friendDefaultConstructorDeclTemplate = R"(
namespace impl {{
std::unique_ptr<::mlir::Pass> create{0}();
} // namespace impl
)";
const char *const friendDefaultConstructorWithOptionsDeclTemplate = R"(
namespace impl {{
[mlir] Pass Options ownership modifications (#110582) This change makes two (related) changes: First, it updates the tablegen option for `ListOption` to emit a `SmallVector` instead of an `ArrayRef`. This brings `ListOption` more inline with the traditional `Option`, where values are typically provided using types that have storage. After this change, all options should be fully owned by a Pass' `Options` object after it has been fully constructed, unless the underlying type of the `Option` explicitly indicates otherwise. Second, it updates the generated constructors for Passes to consume options by value instead of reference, and prefers moving options into the pass itself. This should be more efficient for non-trivial options objects, where the previous interface forced a copy to be materialized. Now, at worst case the API materializes a copy (no worse than before); at best-case, all options objects are moved into place. Ideally, we could update the Pass constructor to take an r-value reference to the Options object instead, but this approach will require numerous changes to existing passes and their factory functions. --------- Authored-by: Nikhil Kalra <nkalra@apple.com>
2024-10-01 09:48:51 -07:00
std::unique_ptr<::mlir::Pass> create{0}({0}Options options);
[MLIR] Fix autogenerated pass constructors linkage The patch addresses the linkage of the new autogenerated pass constructors, which, being declared as friend functions, resulted in having an inline nature and thus their implementations not being exported. Reviewd By: mehdi_amini, rriddle Differential Revision: https://reviews.llvm.org/D132572
2022-08-29 10:57:58 +02:00
} // namespace impl
)";
const char *const friendDefaultConstructorDefTemplate = R"(
[MLIR] Split autogenerated pass declarations & C++ controllable pass options The pass tablegen backend has been reworked to remove the monolithic nature of the autogenerated declarations. The pass public header can be generated with the -gen-pass-decls option. It contains options structs and registrations: the inclusion of options structs can be controlled individually for each pass by defining the GEN_PASS_DECL_PASSNAME macro; the declaration of the registrations have been kept together and can still be included by defining the GEN_PASS_REGISTRATION macro. The private code used for the pass implementation (i.e. the pass base class and the constructors definitions, if missing from tablegen) can be generated with the -gen-pass-defs option. Similarly to the declarations file, the definitions of each pass can be enabled by defining the GEN_PASS_DEF_PASNAME variable. While doing so, the pass base class has been enriched to also accept a the aformentioned struct of options and copy them to the actual pass options, thus allowing each pass to also be configurable within C++ and not only through command line. Reviewed By: rriddle, mehdi_amini, Mogball, jpienaar Differential Revision: https://reviews.llvm.org/D131839
2022-08-24 09:59:50 +02:00
friend std::unique_ptr<::mlir::Pass> create{0}() {{
return std::make_unique<DerivedT>();
}
)";
[MLIR] Fix autogenerated pass constructors linkage The patch addresses the linkage of the new autogenerated pass constructors, which, being declared as friend functions, resulted in having an inline nature and thus their implementations not being exported. Reviewd By: mehdi_amini, rriddle Differential Revision: https://reviews.llvm.org/D132572
2022-08-29 10:57:58 +02:00
const char *const friendDefaultConstructorWithOptionsDefTemplate = R"(
[mlir] Pass Options ownership modifications (#110582) This change makes two (related) changes: First, it updates the tablegen option for `ListOption` to emit a `SmallVector` instead of an `ArrayRef`. This brings `ListOption` more inline with the traditional `Option`, where values are typically provided using types that have storage. After this change, all options should be fully owned by a Pass' `Options` object after it has been fully constructed, unless the underlying type of the `Option` explicitly indicates otherwise. Second, it updates the generated constructors for Passes to consume options by value instead of reference, and prefers moving options into the pass itself. This should be more efficient for non-trivial options objects, where the previous interface forced a copy to be materialized. Now, at worst case the API materializes a copy (no worse than before); at best-case, all options objects are moved into place. Ideally, we could update the Pass constructor to take an r-value reference to the Options object instead, but this approach will require numerous changes to existing passes and their factory functions. --------- Authored-by: Nikhil Kalra <nkalra@apple.com>
2024-10-01 09:48:51 -07:00
friend std::unique_ptr<::mlir::Pass> create{0}({0}Options options) {{
return std::make_unique<DerivedT>(std::move(options));
[MLIR] Split autogenerated pass declarations & C++ controllable pass options The pass tablegen backend has been reworked to remove the monolithic nature of the autogenerated declarations. The pass public header can be generated with the -gen-pass-decls option. It contains options structs and registrations: the inclusion of options structs can be controlled individually for each pass by defining the GEN_PASS_DECL_PASSNAME macro; the declaration of the registrations have been kept together and can still be included by defining the GEN_PASS_REGISTRATION macro. The private code used for the pass implementation (i.e. the pass base class and the constructors definitions, if missing from tablegen) can be generated with the -gen-pass-defs option. Similarly to the declarations file, the definitions of each pass can be enabled by defining the GEN_PASS_DEF_PASNAME variable. While doing so, the pass base class has been enriched to also accept a the aformentioned struct of options and copy them to the actual pass options, thus allowing each pass to also be configurable within C++ and not only through command line. Reviewed By: rriddle, mehdi_amini, Mogball, jpienaar Differential Revision: https://reviews.llvm.org/D131839
2022-08-24 09:59:50 +02:00
}
)";
[MLIR] Fix autogenerated pass constructors linkage The patch addresses the linkage of the new autogenerated pass constructors, which, being declared as friend functions, resulted in having an inline nature and thus their implementations not being exported. Reviewd By: mehdi_amini, rriddle Differential Revision: https://reviews.llvm.org/D132572
2022-08-29 10:57:58 +02:00
const char *const defaultConstructorDefTemplate = R"(
std::unique_ptr<::mlir::Pass> create{0}() {{
return impl::create{0}();
}
)";
const char *const defaultConstructorWithOptionsDefTemplate = R"(
[mlir] Pass Options ownership modifications (#110582) This change makes two (related) changes: First, it updates the tablegen option for `ListOption` to emit a `SmallVector` instead of an `ArrayRef`. This brings `ListOption` more inline with the traditional `Option`, where values are typically provided using types that have storage. After this change, all options should be fully owned by a Pass' `Options` object after it has been fully constructed, unless the underlying type of the `Option` explicitly indicates otherwise. Second, it updates the generated constructors for Passes to consume options by value instead of reference, and prefers moving options into the pass itself. This should be more efficient for non-trivial options objects, where the previous interface forced a copy to be materialized. Now, at worst case the API materializes a copy (no worse than before); at best-case, all options objects are moved into place. Ideally, we could update the Pass constructor to take an r-value reference to the Options object instead, but this approach will require numerous changes to existing passes and their factory functions. --------- Authored-by: Nikhil Kalra <nkalra@apple.com>
2024-10-01 09:48:51 -07:00
std::unique_ptr<::mlir::Pass> create{0}({0}Options options) {{
return impl::create{0}(std::move(options));
[MLIR] Fix autogenerated pass constructors linkage The patch addresses the linkage of the new autogenerated pass constructors, which, being declared as friend functions, resulted in having an inline nature and thus their implementations not being exported. Reviewd By: mehdi_amini, rriddle Differential Revision: https://reviews.llvm.org/D132572
2022-08-29 10:57:58 +02:00
}
)";
[mlir][Pass] Add support for generating pass utilities via tablegen This revision adds support for generating utilities for passes such as options/statistics/etc. that can be inferred from the tablegen definition. This removes additional boilerplate from the pass, and also makes it easier to remove the reliance on the pass registry to provide certain things(e.g. the pass argument). Differential Revision: https://reviews.llvm.org/D76659
2020-04-01 01:50:29 -07:00
/// Emit the declarations for each of the pass options.
static void emitPassOptionDecls(const Pass &pass, raw_ostream &os) {
for (const PassOption &opt : pass.getOptions()) {
[mlir-tblgen] Use fully qualified names in generated code files Using fully qualified names wherever possible avoids ambiguous class and function names. This is a follow-up to D82371. Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D82471
2020-06-26 13:20:44 +02:00
os.indent(2) << "::mlir::Pass::"
<< (opt.isListOption() ? "ListOption" : "Option");
[mlir][Pass] Add support for generating pass utilities via tablegen This revision adds support for generating utilities for passes such as options/statistics/etc. that can be inferred from the tablegen definition. This removes additional boilerplate from the pass, and also makes it easier to remove the reliance on the pass registry to provide certain things(e.g. the pass argument). Differential Revision: https://reviews.llvm.org/D76659
2020-04-01 01:50:29 -07:00
[mlir][tblgen] Avoid compilation failure (#161545) This would have failed during compilation post generation later, trim and use raw string literals to avoid such failures. Probably a few more places where similar failures could occur, but this was unexpected failure user ran into.
2025-10-13 05:55:32 +02:00
os << formatv(R"(<{0}> {1}{{*this, "{2}", ::llvm::cl::desc(R"PO({3})PO"))",
[NFC][MLIR][TableGen] Eliminate `llvm::` for commonly used types (#110841) Eliminate `llvm::` namespace qualifier for commonly used types in MLIR TableGen backends to reduce code clutter.
2024-10-02 13:23:44 -07:00
opt.getType(), opt.getCppVariableName(), opt.getArgument(),
[mlir][tblgen] Avoid compilation failure (#161545) This would have failed during compilation post generation later, trim and use raw string literals to avoid such failures. Probably a few more places where similar failures could occur, but this was unexpected failure user ran into.
2025-10-13 05:55:32 +02:00
opt.getDescription().trim());
[TableGen] llvm::Optional => std::optional
2022-12-06 07:21:02 +00:00
if (std::optional<StringRef> defaultVal = opt.getDefaultValue())
[mlir-tblgen] Use fully qualified names in generated code files Using fully qualified names wherever possible avoids ambiguous class and function names. This is a follow-up to D82371. Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D82471
2020-06-26 13:20:44 +02:00
os << ", ::llvm::cl::init(" << defaultVal << ")";
[TableGen] llvm::Optional => std::optional
2022-12-06 07:21:02 +00:00
if (std::optional<StringRef> additionalFlags = opt.getAdditionalFlags())
[mlir][Pass] Add support for generating pass utilities via tablegen This revision adds support for generating utilities for passes such as options/statistics/etc. that can be inferred from the tablegen definition. This removes additional boilerplate from the pass, and also makes it easier to remove the reliance on the pass registry to provide certain things(e.g. the pass argument). Differential Revision: https://reviews.llvm.org/D76659
2020-04-01 01:50:29 -07:00
os << ", " << *additionalFlags;
os << "};\n";
}
}
/// Emit the declarations for each of the pass statistics.
static void emitPassStatisticDecls(const Pass &pass, raw_ostream &os) {
for (const PassStatistic &stat : pass.getStatistics()) {
[mlir][tblgen] Avoid compilation failure (#161545) This would have failed during compilation post generation later, trim and use raw string literals to avoid such failures. Probably a few more places where similar failures could occur, but this was unexpected failure user ran into.
2025-10-13 05:55:32 +02:00
os << formatv(
" ::mlir::Pass::Statistic {0}{{this, \"{1}\", R\"PS({2})PS\"};\n",
stat.getCppVariableName(), stat.getName(),
stat.getDescription().trim());
[mlir][Pass] Add support for generating pass utilities via tablegen This revision adds support for generating utilities for passes such as options/statistics/etc. that can be inferred from the tablegen definition. This removes additional boilerplate from the pass, and also makes it easier to remove the reliance on the pass registry to provide certain things(e.g. the pass argument). Differential Revision: https://reviews.llvm.org/D76659
2020-04-01 01:50:29 -07:00
}
}
[MLIR] Split autogenerated pass declarations & C++ controllable pass options The pass tablegen backend has been reworked to remove the monolithic nature of the autogenerated declarations. The pass public header can be generated with the -gen-pass-decls option. It contains options structs and registrations: the inclusion of options structs can be controlled individually for each pass by defining the GEN_PASS_DECL_PASSNAME macro; the declaration of the registrations have been kept together and can still be included by defining the GEN_PASS_REGISTRATION macro. The private code used for the pass implementation (i.e. the pass base class and the constructors definitions, if missing from tablegen) can be generated with the -gen-pass-defs option. Similarly to the declarations file, the definitions of each pass can be enabled by defining the GEN_PASS_DEF_PASNAME variable. While doing so, the pass base class has been enriched to also accept a the aformentioned struct of options and copy them to the actual pass options, thus allowing each pass to also be configurable within C++ and not only through command line. Reviewed By: rriddle, mehdi_amini, Mogball, jpienaar Differential Revision: https://reviews.llvm.org/D131839
2022-08-24 09:59:50 +02:00
/// Emit the code to be used in the implementation of the pass.
static void emitPassDefs(const Pass &pass, raw_ostream &os) {
StringRef passName = pass.getDef()->getName();
std::string enableVarName = "GEN_PASS_DEF_" + passName.upper();
[MLIR] Fix autogenerated pass constructors linkage The patch addresses the linkage of the new autogenerated pass constructors, which, being declared as friend functions, resulted in having an inline nature and thus their implementations not being exported. Reviewd By: mehdi_amini, rriddle Differential Revision: https://reviews.llvm.org/D132572
2022-08-29 10:57:58 +02:00
bool emitDefaultConstructors = pass.getConstructor().empty();
bool emitDefaultConstructorWithOptions = !pass.getOptions().empty();
[MLIR] Split autogenerated pass declarations & C++ controllable pass options The pass tablegen backend has been reworked to remove the monolithic nature of the autogenerated declarations. The pass public header can be generated with the -gen-pass-decls option. It contains options structs and registrations: the inclusion of options structs can be controlled individually for each pass by defining the GEN_PASS_DECL_PASSNAME macro; the declaration of the registrations have been kept together and can still be included by defining the GEN_PASS_REGISTRATION macro. The private code used for the pass implementation (i.e. the pass base class and the constructors definitions, if missing from tablegen) can be generated with the -gen-pass-defs option. Similarly to the declarations file, the definitions of each pass can be enabled by defining the GEN_PASS_DEF_PASNAME variable. While doing so, the pass base class has been enriched to also accept a the aformentioned struct of options and copy them to the actual pass options, thus allowing each pass to also be configurable within C++ and not only through command line. Reviewed By: rriddle, mehdi_amini, Mogball, jpienaar Differential Revision: https://reviews.llvm.org/D131839
2022-08-24 09:59:50 +02:00
os << "#ifdef " << enableVarName << "\n";
[MLIR] Fix autogenerated pass constructors linkage The patch addresses the linkage of the new autogenerated pass constructors, which, being declared as friend functions, resulted in having an inline nature and thus their implementations not being exported. Reviewd By: mehdi_amini, rriddle Differential Revision: https://reviews.llvm.org/D132572
2022-08-29 10:57:58 +02:00
if (emitDefaultConstructors) {
[NFC][MLIR][TableGen] Eliminate `llvm::` for commonly used types (#110841) Eliminate `llvm::` namespace qualifier for commonly used types in MLIR TableGen backends to reduce code clutter.
2024-10-02 13:23:44 -07:00
os << formatv(friendDefaultConstructorDeclTemplate, passName);
[MLIR] Fix autogenerated pass constructors linkage The patch addresses the linkage of the new autogenerated pass constructors, which, being declared as friend functions, resulted in having an inline nature and thus their implementations not being exported. Reviewd By: mehdi_amini, rriddle Differential Revision: https://reviews.llvm.org/D132572
2022-08-29 10:57:58 +02:00
if (emitDefaultConstructorWithOptions)
[NFC][MLIR][TableGen] Eliminate `llvm::` for commonly used types (#110841) Eliminate `llvm::` namespace qualifier for commonly used types in MLIR TableGen backends to reduce code clutter.
2024-10-02 13:23:44 -07:00
os << formatv(friendDefaultConstructorWithOptionsDeclTemplate, passName);
[MLIR] Fix autogenerated pass constructors linkage The patch addresses the linkage of the new autogenerated pass constructors, which, being declared as friend functions, resulted in having an inline nature and thus their implementations not being exported. Reviewd By: mehdi_amini, rriddle Differential Revision: https://reviews.llvm.org/D132572
2022-08-29 10:57:58 +02:00
}
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-18 20:01:19 +00:00
std::string dependentDialectRegistrations;
{
llvm::raw_string_ostream dialectsOs(dependentDialectRegistrations);
[mlir] Reformat whitespace in dependent dialects codegen (#78090) The generated code for dependent dialects is awkwardly formatted, making the code harder to read. This change reformats the whitespace to align code in its context and avoid unnecessary empty lines. Also included are some typo fixes. Below are examples of the codegen for a dialect before and after the change. Before: ``` GPUDialect::GPUDialect(::mlir::MLIRContext *context) : ::mlir::Dialect(getDialectNamespace(), context, ::mlir::TypeID::get<GPUDialect>()) { getContext()->loadDialect<arith::ArithDialect>(); initialize(); } ``` After: ``` GPUDialect::GPUDialect(::mlir::MLIRContext *context) : ::mlir::Dialect(getDialectNamespace(), context, ::mlir::TypeID::get<GPUDialect>()) { getContext()->loadDialect<arith::ArithDialect>(); initialize(); } ``` Below are examples of the codegen for a pass before and after the change. Before: ``` /// Return the dialect that must be loaded in the context before this pass. void getDependentDialects(::mlir::DialectRegistry &registry) const override { registry.insert<func::FuncDialect>(); registry.insert<tensor::TensorDialect>(); registry.insert<tosa::TosaDialect>(); } ``` After: ``` /// Register the dialects that must be loaded in the context before this pass. void getDependentDialects(::mlir::DialectRegistry &registry) const override { registry.insert<func::FuncDialect>(); registry.insert<tensor::TensorDialect>(); registry.insert<tosa::TosaDialect>(); } ```
2024-01-15 02:11:52 -08:00
llvm::interleave(
pass.getDependentDialects(), dialectsOs,
[&](StringRef dependentDialect) {
[NFC][MLIR][TableGen] Eliminate `llvm::` for commonly used types (#110841) Eliminate `llvm::` namespace qualifier for commonly used types in MLIR TableGen backends to reduce code clutter.
2024-10-02 13:23:44 -07:00
dialectsOs << formatv(dialectRegistrationTemplate, dependentDialect);
[mlir] Reformat whitespace in dependent dialects codegen (#78090) The generated code for dependent dialects is awkwardly formatted, making the code harder to read. This change reformats the whitespace to align code in its context and avoid unnecessary empty lines. Also included are some typo fixes. Below are examples of the codegen for a dialect before and after the change. Before: ``` GPUDialect::GPUDialect(::mlir::MLIRContext *context) : ::mlir::Dialect(getDialectNamespace(), context, ::mlir::TypeID::get<GPUDialect>()) { getContext()->loadDialect<arith::ArithDialect>(); initialize(); } ``` After: ``` GPUDialect::GPUDialect(::mlir::MLIRContext *context) : ::mlir::Dialect(getDialectNamespace(), context, ::mlir::TypeID::get<GPUDialect>()) { getContext()->loadDialect<arith::ArithDialect>(); initialize(); } ``` Below are examples of the codegen for a pass before and after the change. Before: ``` /// Return the dialect that must be loaded in the context before this pass. void getDependentDialects(::mlir::DialectRegistry &registry) const override { registry.insert<func::FuncDialect>(); registry.insert<tensor::TensorDialect>(); registry.insert<tosa::TosaDialect>(); } ``` After: ``` /// Register the dialects that must be loaded in the context before this pass. void getDependentDialects(::mlir::DialectRegistry &registry) const override { registry.insert<func::FuncDialect>(); registry.insert<tensor::TensorDialect>(); registry.insert<tosa::TosaDialect>(); } ```
2024-01-15 02:11:52 -08:00
},
"\n ");
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-18 20:01:19 +00:00
}
[MLIR] Split autogenerated pass declarations & C++ controllable pass options The pass tablegen backend has been reworked to remove the monolithic nature of the autogenerated declarations. The pass public header can be generated with the -gen-pass-decls option. It contains options structs and registrations: the inclusion of options structs can be controlled individually for each pass by defining the GEN_PASS_DECL_PASSNAME macro; the declaration of the registrations have been kept together and can still be included by defining the GEN_PASS_REGISTRATION macro. The private code used for the pass implementation (i.e. the pass base class and the constructors definitions, if missing from tablegen) can be generated with the -gen-pass-defs option. Similarly to the declarations file, the definitions of each pass can be enabled by defining the GEN_PASS_DEF_PASNAME variable. While doing so, the pass base class has been enriched to also accept a the aformentioned struct of options and copy them to the actual pass options, thus allowing each pass to also be configurable within C++ and not only through command line. Reviewed By: rriddle, mehdi_amini, Mogball, jpienaar Differential Revision: https://reviews.llvm.org/D131839
2022-08-24 09:59:50 +02:00
[MLIR] Fix autogenerated pass constructors linkage The patch addresses the linkage of the new autogenerated pass constructors, which, being declared as friend functions, resulted in having an inline nature and thus their implementations not being exported. Reviewd By: mehdi_amini, rriddle Differential Revision: https://reviews.llvm.org/D132572
2022-08-29 10:57:58 +02:00
os << "namespace impl {\n";
[NFC][MLIR][TableGen] Eliminate `llvm::` for commonly used types (#110841) Eliminate `llvm::` namespace qualifier for commonly used types in MLIR TableGen backends to reduce code clutter.
2024-10-02 13:23:44 -07:00
os << formatv(baseClassBegin, passName, pass.getBaseClass(),
[mlir][tblgen] Avoid compilation failure (#161545) This would have failed during compilation post generation later, trim and use raw string literals to avoid such failures. Probably a few more places where similar failures could occur, but this was unexpected failure user ran into.
2025-10-13 05:55:32 +02:00
pass.getArgument(), pass.getSummary().trim(),
[NFC][MLIR][TableGen] Eliminate `llvm::` for commonly used types (#110841) Eliminate `llvm::` namespace qualifier for commonly used types in MLIR TableGen backends to reduce code clutter.
2024-10-02 13:23:44 -07:00
dependentDialectRegistrations);
[MLIR] Split autogenerated pass declarations & C++ controllable pass options The pass tablegen backend has been reworked to remove the monolithic nature of the autogenerated declarations. The pass public header can be generated with the -gen-pass-decls option. It contains options structs and registrations: the inclusion of options structs can be controlled individually for each pass by defining the GEN_PASS_DECL_PASSNAME macro; the declaration of the registrations have been kept together and can still be included by defining the GEN_PASS_REGISTRATION macro. The private code used for the pass implementation (i.e. the pass base class and the constructors definitions, if missing from tablegen) can be generated with the -gen-pass-defs option. Similarly to the declarations file, the definitions of each pass can be enabled by defining the GEN_PASS_DEF_PASNAME variable. While doing so, the pass base class has been enriched to also accept a the aformentioned struct of options and copy them to the actual pass options, thus allowing each pass to also be configurable within C++ and not only through command line. Reviewed By: rriddle, mehdi_amini, Mogball, jpienaar Differential Revision: https://reviews.llvm.org/D131839
2022-08-24 09:59:50 +02:00
if (ArrayRef<PassOption> options = pass.getOptions(); !options.empty()) {
[NFC][MLIR][TableGen] Eliminate `llvm::` for commonly used types (#110841) Eliminate `llvm::` namespace qualifier for commonly used types in MLIR TableGen backends to reduce code clutter.
2024-10-02 13:23:44 -07:00
os.indent(2) << formatv("{0}Base({0}Options options) : {0}Base() {{\n",
passName);
[MLIR] Split autogenerated pass declarations & C++ controllable pass options The pass tablegen backend has been reworked to remove the monolithic nature of the autogenerated declarations. The pass public header can be generated with the -gen-pass-decls option. It contains options structs and registrations: the inclusion of options structs can be controlled individually for each pass by defining the GEN_PASS_DECL_PASSNAME macro; the declaration of the registrations have been kept together and can still be included by defining the GEN_PASS_REGISTRATION macro. The private code used for the pass implementation (i.e. the pass base class and the constructors definitions, if missing from tablegen) can be generated with the -gen-pass-defs option. Similarly to the declarations file, the definitions of each pass can be enabled by defining the GEN_PASS_DEF_PASNAME variable. While doing so, the pass base class has been enriched to also accept a the aformentioned struct of options and copy them to the actual pass options, thus allowing each pass to also be configurable within C++ and not only through command line. Reviewed By: rriddle, mehdi_amini, Mogball, jpienaar Differential Revision: https://reviews.llvm.org/D131839
2022-08-24 09:59:50 +02:00
for (const PassOption &opt : pass.getOptions())
[NFC][MLIR][TableGen] Eliminate `llvm::` for commonly used types (#110841) Eliminate `llvm::` namespace qualifier for commonly used types in MLIR TableGen backends to reduce code clutter.
2024-10-02 13:23:44 -07:00
os.indent(4) << formatv("{0} = std::move(options.{0});\n",
opt.getCppVariableName());
[MLIR] Split autogenerated pass declarations & C++ controllable pass options The pass tablegen backend has been reworked to remove the monolithic nature of the autogenerated declarations. The pass public header can be generated with the -gen-pass-decls option. It contains options structs and registrations: the inclusion of options structs can be controlled individually for each pass by defining the GEN_PASS_DECL_PASSNAME macro; the declaration of the registrations have been kept together and can still be included by defining the GEN_PASS_REGISTRATION macro. The private code used for the pass implementation (i.e. the pass base class and the constructors definitions, if missing from tablegen) can be generated with the -gen-pass-defs option. Similarly to the declarations file, the definitions of each pass can be enabled by defining the GEN_PASS_DEF_PASNAME variable. While doing so, the pass base class has been enriched to also accept a the aformentioned struct of options and copy them to the actual pass options, thus allowing each pass to also be configurable within C++ and not only through command line. Reviewed By: rriddle, mehdi_amini, Mogball, jpienaar Differential Revision: https://reviews.llvm.org/D131839
2022-08-24 09:59:50 +02:00
os.indent(2) << "}\n";
}
// Protected content
os << "protected:\n";
[mlir][Pass] Add support for generating pass utilities via tablegen This revision adds support for generating utilities for passes such as options/statistics/etc. that can be inferred from the tablegen definition. This removes additional boilerplate from the pass, and also makes it easier to remove the reliance on the pass registry to provide certain things(e.g. the pass argument). Differential Revision: https://reviews.llvm.org/D76659
2020-04-01 01:50:29 -07:00
emitPassOptionDecls(pass, os);
emitPassStatisticDecls(pass, os);
[MLIR] Split autogenerated pass declarations & C++ controllable pass options The pass tablegen backend has been reworked to remove the monolithic nature of the autogenerated declarations. The pass public header can be generated with the -gen-pass-decls option. It contains options structs and registrations: the inclusion of options structs can be controlled individually for each pass by defining the GEN_PASS_DECL_PASSNAME macro; the declaration of the registrations have been kept together and can still be included by defining the GEN_PASS_REGISTRATION macro. The private code used for the pass implementation (i.e. the pass base class and the constructors definitions, if missing from tablegen) can be generated with the -gen-pass-defs option. Similarly to the declarations file, the definitions of each pass can be enabled by defining the GEN_PASS_DEF_PASNAME variable. While doing so, the pass base class has been enriched to also accept a the aformentioned struct of options and copy them to the actual pass options, thus allowing each pass to also be configurable within C++ and not only through command line. Reviewed By: rriddle, mehdi_amini, Mogball, jpienaar Differential Revision: https://reviews.llvm.org/D131839
2022-08-24 09:59:50 +02:00
// Private content
os << "private:\n";
[MLIR] Fix autogenerated pass constructors linkage The patch addresses the linkage of the new autogenerated pass constructors, which, being declared as friend functions, resulted in having an inline nature and thus their implementations not being exported. Reviewd By: mehdi_amini, rriddle Differential Revision: https://reviews.llvm.org/D132572
2022-08-29 10:57:58 +02:00
if (emitDefaultConstructors) {
[NFC][MLIR][TableGen] Eliminate `llvm::` for commonly used types (#110841) Eliminate `llvm::` namespace qualifier for commonly used types in MLIR TableGen backends to reduce code clutter.
2024-10-02 13:23:44 -07:00
os << formatv(friendDefaultConstructorDefTemplate, passName);
[MLIR] Split autogenerated pass declarations & C++ controllable pass options The pass tablegen backend has been reworked to remove the monolithic nature of the autogenerated declarations. The pass public header can be generated with the -gen-pass-decls option. It contains options structs and registrations: the inclusion of options structs can be controlled individually for each pass by defining the GEN_PASS_DECL_PASSNAME macro; the declaration of the registrations have been kept together and can still be included by defining the GEN_PASS_REGISTRATION macro. The private code used for the pass implementation (i.e. the pass base class and the constructors definitions, if missing from tablegen) can be generated with the -gen-pass-defs option. Similarly to the declarations file, the definitions of each pass can be enabled by defining the GEN_PASS_DEF_PASNAME variable. While doing so, the pass base class has been enriched to also accept a the aformentioned struct of options and copy them to the actual pass options, thus allowing each pass to also be configurable within C++ and not only through command line. Reviewed By: rriddle, mehdi_amini, Mogball, jpienaar Differential Revision: https://reviews.llvm.org/D131839
2022-08-24 09:59:50 +02:00
if (!pass.getOptions().empty())
[NFC][MLIR][TableGen] Eliminate `llvm::` for commonly used types (#110841) Eliminate `llvm::` namespace qualifier for commonly used types in MLIR TableGen backends to reduce code clutter.
2024-10-02 13:23:44 -07:00
os << formatv(friendDefaultConstructorWithOptionsDefTemplate, passName);
[MLIR] Split autogenerated pass declarations & C++ controllable pass options The pass tablegen backend has been reworked to remove the monolithic nature of the autogenerated declarations. The pass public header can be generated with the -gen-pass-decls option. It contains options structs and registrations: the inclusion of options structs can be controlled individually for each pass by defining the GEN_PASS_DECL_PASSNAME macro; the declaration of the registrations have been kept together and can still be included by defining the GEN_PASS_REGISTRATION macro. The private code used for the pass implementation (i.e. the pass base class and the constructors definitions, if missing from tablegen) can be generated with the -gen-pass-defs option. Similarly to the declarations file, the definitions of each pass can be enabled by defining the GEN_PASS_DEF_PASNAME variable. While doing so, the pass base class has been enriched to also accept a the aformentioned struct of options and copy them to the actual pass options, thus allowing each pass to also be configurable within C++ and not only through command line. Reviewed By: rriddle, mehdi_amini, Mogball, jpienaar Differential Revision: https://reviews.llvm.org/D131839
2022-08-24 09:59:50 +02:00
}
[mlir][Pass] Update the PassGen to generate base classes instead of utilities Summary: This is much cleaner, and fits the same structure as many other tablegen backends. This was not done originally as the CRTP in the pass classes made it overly verbose/complex. Differential Revision: https://reviews.llvm.org/D77367
2020-04-07 13:58:12 -07:00
os << "};\n";
[MLIR] Fix autogenerated pass constructors linkage The patch addresses the linkage of the new autogenerated pass constructors, which, being declared as friend functions, resulted in having an inline nature and thus their implementations not being exported. Reviewd By: mehdi_amini, rriddle Differential Revision: https://reviews.llvm.org/D132572
2022-08-29 10:57:58 +02:00
os << "} // namespace impl\n";
if (emitDefaultConstructors) {
[NFC][MLIR][TableGen] Eliminate `llvm::` for commonly used types (#110841) Eliminate `llvm::` namespace qualifier for commonly used types in MLIR TableGen backends to reduce code clutter.
2024-10-02 13:23:44 -07:00
os << formatv(defaultConstructorDefTemplate, passName);
[MLIR] Fix autogenerated pass constructors linkage The patch addresses the linkage of the new autogenerated pass constructors, which, being declared as friend functions, resulted in having an inline nature and thus their implementations not being exported. Reviewd By: mehdi_amini, rriddle Differential Revision: https://reviews.llvm.org/D132572
2022-08-29 10:57:58 +02:00
if (emitDefaultConstructorWithOptions)
[NFC][MLIR][TableGen] Eliminate `llvm::` for commonly used types (#110841) Eliminate `llvm::` namespace qualifier for commonly used types in MLIR TableGen backends to reduce code clutter.
2024-10-02 13:23:44 -07:00
os << formatv(defaultConstructorWithOptionsDefTemplate, passName);
[MLIR] Fix autogenerated pass constructors linkage The patch addresses the linkage of the new autogenerated pass constructors, which, being declared as friend functions, resulted in having an inline nature and thus their implementations not being exported. Reviewd By: mehdi_amini, rriddle Differential Revision: https://reviews.llvm.org/D132572
2022-08-29 10:57:58 +02:00
}
[MLIR] Split autogenerated pass declarations & C++ controllable pass options The pass tablegen backend has been reworked to remove the monolithic nature of the autogenerated declarations. The pass public header can be generated with the -gen-pass-decls option. It contains options structs and registrations: the inclusion of options structs can be controlled individually for each pass by defining the GEN_PASS_DECL_PASSNAME macro; the declaration of the registrations have been kept together and can still be included by defining the GEN_PASS_REGISTRATION macro. The private code used for the pass implementation (i.e. the pass base class and the constructors definitions, if missing from tablegen) can be generated with the -gen-pass-defs option. Similarly to the declarations file, the definitions of each pass can be enabled by defining the GEN_PASS_DEF_PASNAME variable. While doing so, the pass base class has been enriched to also accept a the aformentioned struct of options and copy them to the actual pass options, thus allowing each pass to also be configurable within C++ and not only through command line. Reviewed By: rriddle, mehdi_amini, Mogball, jpienaar Differential Revision: https://reviews.llvm.org/D131839
2022-08-24 09:59:50 +02:00
os << "#undef " << enableVarName << "\n";
os << "#endif // " << enableVarName << "\n";
[mlir][Pass] Update the PassGen to generate base classes instead of utilities Summary: This is much cleaner, and fits the same structure as many other tablegen backends. This was not done originally as the CRTP in the pass classes made it overly verbose/complex. Differential Revision: https://reviews.llvm.org/D77367
2020-04-07 13:58:12 -07:00
}
[MLIR] Unique autogenerated file for tablegen passes Being the generated code macro-guarded, the autogenerated `.cpp.inc` file has been merged into the `.h.inc` to reduce the build steps. Reviewed By: mehdi_amini, rriddle Differential Revision: https://reviews.llvm.org/D132884
2022-08-30 09:48:11 +02:00
static void emitPass(const Pass &pass, raw_ostream &os) {
StringRef passName = pass.getDef()->getName();
[NFC][MLIR][TableGen] Eliminate `llvm::` for commonly used types (#110841) Eliminate `llvm::` namespace qualifier for commonly used types in MLIR TableGen backends to reduce code clutter.
2024-10-02 13:23:44 -07:00
os << formatv(passHeader, passName);
[MLIR] Unique autogenerated file for tablegen passes Being the generated code macro-guarded, the autogenerated `.cpp.inc` file has been merged into the `.h.inc` to reduce the build steps. Reviewed By: mehdi_amini, rriddle Differential Revision: https://reviews.llvm.org/D132884
2022-08-30 09:48:11 +02:00
emitPassDecls(pass, os);
emitPassDefs(pass, os);
}
[MLIR] Keep but deprecate old autogenerated pass base classes Restore the generation of the old pass base classes for better transitioning of external projects relying on them. They were eliminated with 67d0d7ac0acb0665d6a09f61278fbcf51f0114c2. Reviewed By: rsmith Differential Revision: https://reviews.llvm.org/D133027
2022-08-31 23:38:31 +02:00
// TODO: Drop old pass declarations.
// The old pass base class is being kept until all the passes have switched to
// the new decls/defs design.
const char *const oldPassDeclBegin = R"(
template <typename DerivedT>
class {0}Base : public {1} {
public:
using Base = {0}Base;
{0}Base() : {1}(::mlir::TypeID::get<DerivedT>()) {{}
{0}Base(const {0}Base &other) : {1}(other) {{}
[mlir][NFC] Apply rule of five to *Pass classes (#80998) Define all special member functions for mlir::Pass, mlir::OperationPass, mlir::PassWrapper and PassGen types since these classes explicitly specify copy-ctor. This, subsequently, should silence static analysis checkers that report rule-of-3 / rule-of-5 violations. Given the nature of the types, however, mark other special member functions deleted: the semantics of a Pass type object seems to be that it is only ever created by being wrapped in a smart pointer, so the special member functions are never to be used externally (except for the copy-ctor - it is "special" since it is a "delegating" ctor for derived pass types to use during cloning - see https://reviews.llvm.org/D104302 for details). Deleting other member functions means that `Pass x(std::move(y))` - that used to silently work (via copy-ctor) - would fail to compile now. Yet, as the copy ctors through the hierarchy are under 'protected' access, the issue is unlikely to appear in practice. Co-authored-by: Asya Pronina <anastasiya.pronina@intel.com> Co-authored-by: Harald Rotuna <harald.razvan.rotuna@intel.com>
2024-03-05 09:07:43 +02:00
{0}Base& operator=(const {0}Base &) = delete;
{0}Base({0}Base &&) = delete;
{0}Base& operator=({0}Base &&) = delete;
~{0}Base() = default;
[MLIR] Keep but deprecate old autogenerated pass base classes Restore the generation of the old pass base classes for better transitioning of external projects relying on them. They were eliminated with 67d0d7ac0acb0665d6a09f61278fbcf51f0114c2. Reviewed By: rsmith Differential Revision: https://reviews.llvm.org/D133027
2022-08-31 23:38:31 +02:00
/// Returns the command-line argument attached to this pass.
static constexpr ::llvm::StringLiteral getArgumentName() {
return ::llvm::StringLiteral("{2}");
}
::llvm::StringRef getArgument() const override { return "{2}"; }
[mlir][tblgen] Avoid compilation failure (#161545) This would have failed during compilation post generation later, trim and use raw string literals to avoid such failures. Probably a few more places where similar failures could occur, but this was unexpected failure user ran into.
2025-10-13 05:55:32 +02:00
::llvm::StringRef getDescription() const override { return R"PD({3})PD"; }
[MLIR] Keep but deprecate old autogenerated pass base classes Restore the generation of the old pass base classes for better transitioning of external projects relying on them. They were eliminated with 67d0d7ac0acb0665d6a09f61278fbcf51f0114c2. Reviewed By: rsmith Differential Revision: https://reviews.llvm.org/D133027
2022-08-31 23:38:31 +02:00
/// Returns the derived pass name.
static constexpr ::llvm::StringLiteral getPassName() {
return ::llvm::StringLiteral("{0}");
}
::llvm::StringRef getName() const override { return "{0}"; }
/// Support isa/dyn_cast functionality for the derived pass class.
static bool classof(const ::mlir::Pass *pass) {{
return pass->getTypeID() == ::mlir::TypeID::get<DerivedT>();
}
/// A clone method to create a copy of this pass.
std::unique_ptr<::mlir::Pass> clonePass() const override {{
return std::make_unique<DerivedT>(*static_cast<const DerivedT *>(this));
}
[mlir] Reformat whitespace in dependent dialects codegen (#78090) The generated code for dependent dialects is awkwardly formatted, making the code harder to read. This change reformats the whitespace to align code in its context and avoid unnecessary empty lines. Also included are some typo fixes. Below are examples of the codegen for a dialect before and after the change. Before: ``` GPUDialect::GPUDialect(::mlir::MLIRContext *context) : ::mlir::Dialect(getDialectNamespace(), context, ::mlir::TypeID::get<GPUDialect>()) { getContext()->loadDialect<arith::ArithDialect>(); initialize(); } ``` After: ``` GPUDialect::GPUDialect(::mlir::MLIRContext *context) : ::mlir::Dialect(getDialectNamespace(), context, ::mlir::TypeID::get<GPUDialect>()) { getContext()->loadDialect<arith::ArithDialect>(); initialize(); } ``` Below are examples of the codegen for a pass before and after the change. Before: ``` /// Return the dialect that must be loaded in the context before this pass. void getDependentDialects(::mlir::DialectRegistry &registry) const override { registry.insert<func::FuncDialect>(); registry.insert<tensor::TensorDialect>(); registry.insert<tosa::TosaDialect>(); } ``` After: ``` /// Register the dialects that must be loaded in the context before this pass. void getDependentDialects(::mlir::DialectRegistry &registry) const override { registry.insert<func::FuncDialect>(); registry.insert<tensor::TensorDialect>(); registry.insert<tosa::TosaDialect>(); } ```
2024-01-15 02:11:52 -08:00
/// Register the dialects that must be loaded in the context before this pass.
[MLIR] Keep but deprecate old autogenerated pass base classes Restore the generation of the old pass base classes for better transitioning of external projects relying on them. They were eliminated with 67d0d7ac0acb0665d6a09f61278fbcf51f0114c2. Reviewed By: rsmith Differential Revision: https://reviews.llvm.org/D133027
2022-08-31 23:38:31 +02:00
void getDependentDialects(::mlir::DialectRegistry &registry) const override {
{4}
}
/// Explicitly declare the TypeID for this class. We declare an explicit private
/// instantiation because Pass classes should only be visible by the current
/// library.
MLIR_DEFINE_EXPLICIT_INTERNAL_INLINE_TYPE_ID({0}Base<DerivedT>)
protected:
)";
// TODO: Drop old pass declarations.
/// Emit a backward-compatible declaration of the pass base class.
static void emitOldPassDecl(const Pass &pass, raw_ostream &os) {
StringRef defName = pass.getDef()->getName();
std::string dependentDialectRegistrations;
{
llvm::raw_string_ostream dialectsOs(dependentDialectRegistrations);
[mlir] Reformat whitespace in dependent dialects codegen (#78090) The generated code for dependent dialects is awkwardly formatted, making the code harder to read. This change reformats the whitespace to align code in its context and avoid unnecessary empty lines. Also included are some typo fixes. Below are examples of the codegen for a dialect before and after the change. Before: ``` GPUDialect::GPUDialect(::mlir::MLIRContext *context) : ::mlir::Dialect(getDialectNamespace(), context, ::mlir::TypeID::get<GPUDialect>()) { getContext()->loadDialect<arith::ArithDialect>(); initialize(); } ``` After: ``` GPUDialect::GPUDialect(::mlir::MLIRContext *context) : ::mlir::Dialect(getDialectNamespace(), context, ::mlir::TypeID::get<GPUDialect>()) { getContext()->loadDialect<arith::ArithDialect>(); initialize(); } ``` Below are examples of the codegen for a pass before and after the change. Before: ``` /// Return the dialect that must be loaded in the context before this pass. void getDependentDialects(::mlir::DialectRegistry &registry) const override { registry.insert<func::FuncDialect>(); registry.insert<tensor::TensorDialect>(); registry.insert<tosa::TosaDialect>(); } ``` After: ``` /// Register the dialects that must be loaded in the context before this pass. void getDependentDialects(::mlir::DialectRegistry &registry) const override { registry.insert<func::FuncDialect>(); registry.insert<tensor::TensorDialect>(); registry.insert<tosa::TosaDialect>(); } ```
2024-01-15 02:11:52 -08:00
llvm::interleave(
pass.getDependentDialects(), dialectsOs,
[&](StringRef dependentDialect) {
[NFC][MLIR][TableGen] Eliminate `llvm::` for commonly used types (#110841) Eliminate `llvm::` namespace qualifier for commonly used types in MLIR TableGen backends to reduce code clutter.
2024-10-02 13:23:44 -07:00
dialectsOs << formatv(dialectRegistrationTemplate, dependentDialect);
[mlir] Reformat whitespace in dependent dialects codegen (#78090) The generated code for dependent dialects is awkwardly formatted, making the code harder to read. This change reformats the whitespace to align code in its context and avoid unnecessary empty lines. Also included are some typo fixes. Below are examples of the codegen for a dialect before and after the change. Before: ``` GPUDialect::GPUDialect(::mlir::MLIRContext *context) : ::mlir::Dialect(getDialectNamespace(), context, ::mlir::TypeID::get<GPUDialect>()) { getContext()->loadDialect<arith::ArithDialect>(); initialize(); } ``` After: ``` GPUDialect::GPUDialect(::mlir::MLIRContext *context) : ::mlir::Dialect(getDialectNamespace(), context, ::mlir::TypeID::get<GPUDialect>()) { getContext()->loadDialect<arith::ArithDialect>(); initialize(); } ``` Below are examples of the codegen for a pass before and after the change. Before: ``` /// Return the dialect that must be loaded in the context before this pass. void getDependentDialects(::mlir::DialectRegistry &registry) const override { registry.insert<func::FuncDialect>(); registry.insert<tensor::TensorDialect>(); registry.insert<tosa::TosaDialect>(); } ``` After: ``` /// Register the dialects that must be loaded in the context before this pass. void getDependentDialects(::mlir::DialectRegistry &registry) const override { registry.insert<func::FuncDialect>(); registry.insert<tensor::TensorDialect>(); registry.insert<tosa::TosaDialect>(); } ```
2024-01-15 02:11:52 -08:00
},
"\n ");
[MLIR] Keep but deprecate old autogenerated pass base classes Restore the generation of the old pass base classes for better transitioning of external projects relying on them. They were eliminated with 67d0d7ac0acb0665d6a09f61278fbcf51f0114c2. Reviewed By: rsmith Differential Revision: https://reviews.llvm.org/D133027
2022-08-31 23:38:31 +02:00
}
[NFC][MLIR][TableGen] Eliminate `llvm::` for commonly used types (#110841) Eliminate `llvm::` namespace qualifier for commonly used types in MLIR TableGen backends to reduce code clutter.
2024-10-02 13:23:44 -07:00
os << formatv(oldPassDeclBegin, defName, pass.getBaseClass(),
[mlir][tblgen] Avoid compilation failure (#161545) This would have failed during compilation post generation later, trim and use raw string literals to avoid such failures. Probably a few more places where similar failures could occur, but this was unexpected failure user ran into.
2025-10-13 05:55:32 +02:00
pass.getArgument(), pass.getSummary().trim(),
[NFC][MLIR][TableGen] Eliminate `llvm::` for commonly used types (#110841) Eliminate `llvm::` namespace qualifier for commonly used types in MLIR TableGen backends to reduce code clutter.
2024-10-02 13:23:44 -07:00
dependentDialectRegistrations);
[MLIR] Keep but deprecate old autogenerated pass base classes Restore the generation of the old pass base classes for better transitioning of external projects relying on them. They were eliminated with 67d0d7ac0acb0665d6a09f61278fbcf51f0114c2. Reviewed By: rsmith Differential Revision: https://reviews.llvm.org/D133027
2022-08-31 23:38:31 +02:00
emitPassOptionDecls(pass, os);
emitPassStatisticDecls(pass, os);
os << "};\n";
}
[NFC] Rename variable `recordKeeper` to `records` (#110989)
2024-10-03 06:30:31 -07:00
static void emitPasses(const RecordKeeper &records, raw_ostream &os) {
std::vector<Pass> passes = getPasses(records);
[MLIR] Unique autogenerated file for tablegen passes Being the generated code macro-guarded, the autogenerated `.cpp.inc` file has been merged into the `.h.inc` to reduce the build steps. Reviewed By: mehdi_amini, rriddle Differential Revision: https://reviews.llvm.org/D132884
2022-08-30 09:48:11 +02:00
os << "/* Autogenerated by mlir-tblgen; don't manually edit */\n";
[mlir] Add macro for enabling all generated pass declarations Currently the generated pass declarations have to be enabled per-pass using multiple `GEN_PASS_DECL_{PASSNAME}` defines. This adds `GEN_PASS_DECL`, which enables the declarations for all passes in the group with a single macro. This is convenient for cases where a single header is used for all passes in the group. Reviewed By: mehdi_amini, mscuttari Differential Revision: https://reviews.llvm.org/D134766
2022-09-27 17:23:59 -04:00
os << "\n";
os << "#ifdef GEN_PASS_DECL\n";
os << "// Generate declarations for all passes.\n";
for (const Pass &pass : passes)
os << "#define " << getPassDeclVarName(pass) << "\n";
os << "#undef GEN_PASS_DECL\n";
os << "#endif // GEN_PASS_DECL\n";
[MLIR] Unique autogenerated file for tablegen passes Being the generated code macro-guarded, the autogenerated `.cpp.inc` file has been merged into the `.h.inc` to reduce the build steps. Reviewed By: mehdi_amini, rriddle Differential Revision: https://reviews.llvm.org/D132884
2022-08-30 09:48:11 +02:00
for (const Pass &pass : passes)
emitPass(pass, os);
emitRegistrations(passes, os);
[MLIR] Keep but deprecate old autogenerated pass base classes Restore the generation of the old pass base classes for better transitioning of external projects relying on them. They were eliminated with 67d0d7ac0acb0665d6a09f61278fbcf51f0114c2. Reviewed By: rsmith Differential Revision: https://reviews.llvm.org/D133027
2022-08-31 23:38:31 +02:00
// TODO: Drop old pass declarations.
// Emit the old code until all the passes have switched to the new design.
os << "// Deprecated. Please use the new per-pass macros.\n";
os << "#ifdef GEN_PASS_CLASSES\n";
for (const Pass &pass : passes)
emitOldPassDecl(pass, os);
os << "#undef GEN_PASS_CLASSES\n";
os << "#endif // GEN_PASS_CLASSES\n";
[MLIR] Unique autogenerated file for tablegen passes Being the generated code macro-guarded, the autogenerated `.cpp.inc` file has been merged into the `.h.inc` to reduce the build steps. Reviewed By: mehdi_amini, rriddle Differential Revision: https://reviews.llvm.org/D132884
2022-08-30 09:48:11 +02:00
}
[mlir][Pass] Add a tablegen backend for defining Pass information This will greatly simplify a number of things related to passes: * Enables generation of pass registration * Enables generation of boiler plate pass utilities * Enables generation of pass documentation This revision focuses on adding the basic structure and adds support for generating the registration for passes in the Transforms/ directory. Future revisions will add more support and move more passes over. Differential Revision: https://reviews.llvm.org/D76656
2020-04-01 01:48:34 -07:00
static mlir::GenRegistration
[MLIR] Split autogenerated pass declarations & C++ controllable pass options The pass tablegen backend has been reworked to remove the monolithic nature of the autogenerated declarations. The pass public header can be generated with the -gen-pass-decls option. It contains options structs and registrations: the inclusion of options structs can be controlled individually for each pass by defining the GEN_PASS_DECL_PASSNAME macro; the declaration of the registrations have been kept together and can still be included by defining the GEN_PASS_REGISTRATION macro. The private code used for the pass implementation (i.e. the pass base class and the constructors definitions, if missing from tablegen) can be generated with the -gen-pass-defs option. Similarly to the declarations file, the definitions of each pass can be enabled by defining the GEN_PASS_DEF_PASNAME variable. While doing so, the pass base class has been enriched to also accept a the aformentioned struct of options and copy them to the actual pass options, thus allowing each pass to also be configurable within C++ and not only through command line. Reviewed By: rriddle, mehdi_amini, Mogball, jpienaar Differential Revision: https://reviews.llvm.org/D131839
2022-08-24 09:59:50 +02:00
genPassDecls("gen-pass-decls", "Generate pass declarations",
[NFC][MLIR][TableGen] Eliminate `llvm::` for commonly used types (#110841) Eliminate `llvm::` namespace qualifier for commonly used types in MLIR TableGen backends to reduce code clutter.
2024-10-02 13:23:44 -07:00
[](const RecordKeeper &records, raw_ostream &os) {
[MLIR] Unique autogenerated file for tablegen passes Being the generated code macro-guarded, the autogenerated `.cpp.inc` file has been merged into the `.h.inc` to reduce the build steps. Reviewed By: mehdi_amini, rriddle Differential Revision: https://reviews.llvm.org/D132884
2022-08-30 09:48:11 +02:00
emitPasses(records, os);
[MLIR] Split autogenerated pass declarations & C++ controllable pass options The pass tablegen backend has been reworked to remove the monolithic nature of the autogenerated declarations. The pass public header can be generated with the -gen-pass-decls option. It contains options structs and registrations: the inclusion of options structs can be controlled individually for each pass by defining the GEN_PASS_DECL_PASSNAME macro; the declaration of the registrations have been kept together and can still be included by defining the GEN_PASS_REGISTRATION macro. The private code used for the pass implementation (i.e. the pass base class and the constructors definitions, if missing from tablegen) can be generated with the -gen-pass-defs option. Similarly to the declarations file, the definitions of each pass can be enabled by defining the GEN_PASS_DEF_PASNAME variable. While doing so, the pass base class has been enriched to also accept a the aformentioned struct of options and copy them to the actual pass options, thus allowing each pass to also be configurable within C++ and not only through command line. Reviewed By: rriddle, mehdi_amini, Mogball, jpienaar Differential Revision: https://reviews.llvm.org/D131839
2022-08-24 09:59:50 +02:00
return false;
});
Reference in New Issue Copy Permalink