2018-06-22 22:03:48 -07:00
|
|
|
//===- MLIRContext.cpp - MLIR Type Classes --------------------------------===//
|
|
|
|
//
|
2020-01-26 03:58:30 +00:00
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
2019-12-23 09:35:36 -08:00
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
2018-06-22 22:03:48 -07:00
|
|
|
//
|
2019-12-23 09:35:36 -08:00
|
|
|
//===----------------------------------------------------------------------===//
|
2018-06-22 22:03:48 -07:00
|
|
|
|
|
|
|
#include "mlir/IR/MLIRContext.h"
|
2018-10-09 10:59:27 -07:00
|
|
|
#include "AffineExprDetail.h"
|
2018-10-09 16:39:24 -07:00
|
|
|
#include "AffineMapDetail.h"
|
2018-10-25 15:46:10 -07:00
|
|
|
#include "AttributeDetail.h"
|
2018-10-10 09:45:59 -07:00
|
|
|
#include "IntegerSetDetail.h"
|
2018-10-30 14:59:22 -07:00
|
|
|
#include "TypeDetail.h"
|
2018-06-29 18:09:29 -07:00
|
|
|
#include "mlir/IR/AffineExpr.h"
|
|
|
|
#include "mlir/IR/AffineMap.h"
|
2018-07-04 10:43:29 -07:00
|
|
|
#include "mlir/IR/Attributes.h"
|
2020-11-17 00:38:10 -08:00
|
|
|
#include "mlir/IR/BuiltinDialect.h"
|
2019-05-01 11:14:15 -07:00
|
|
|
#include "mlir/IR/Diagnostics.h"
|
2019-03-01 16:58:00 -08:00
|
|
|
#include "mlir/IR/Dialect.h"
|
2022-09-19 09:47:37 -07:00
|
|
|
#include "mlir/IR/ExtensibleDialect.h"
|
2018-08-07 14:24:38 -07:00
|
|
|
#include "mlir/IR/IntegerSet.h"
|
2018-08-27 21:05:16 -07:00
|
|
|
#include "mlir/IR/Location.h"
|
2020-10-30 00:30:59 -07:00
|
|
|
#include "mlir/IR/OpImplementation.h"
|
2018-06-22 22:03:48 -07:00
|
|
|
#include "mlir/IR/Types.h"
|
[mlir] Add a new debug action framework.
This revision adds the infrastructure for `Debug Actions`. This is a DEBUG only
API that allows for external entities to control various aspects of compiler
execution. This is conceptually similar to something like DebugCounters in LLVM, but at a lower level. This framework doesn't make any assumptions about how the higher level driver is controlling the execution, it merely provides a framework for connecting the two together. This means that on top of DebugCounter functionality, we could also provide more interesting drivers such as interactive execution. A high level overview of the workflow surrounding debug actions is
shown below:
* Compiler developer defines an `action` that is taken by the a pass,
transformation, utility that they are developing.
* Depending on the needs, the developer dispatches various queries, pertaining
to this action, to an `action manager` that will provide an answer as to
what behavior the action should do.
* An external entity registers an `action handler` with the action manager,
and provides the logic to resolve queries on actions.
The exact definition of an `external entity` is left opaque, to allow for more
interesting handlers.
This framework was proposed here: https://llvm.discourse.group/t/rfc-debug-actions-in-mlir-debug-counters-for-the-modern-world
Differential Revision: https://reviews.llvm.org/D84986
2021-02-23 00:51:49 -08:00
|
|
|
#include "mlir/Support/DebugAction.h"
|
2019-08-01 16:38:26 -07:00
|
|
|
#include "llvm/ADT/DenseMap.h"
|
2018-06-22 22:03:48 -07:00
|
|
|
#include "llvm/ADT/DenseSet.h"
|
2021-04-21 10:48:54 -04:00
|
|
|
#include "llvm/ADT/SmallString.h"
|
2020-04-11 22:06:45 -07:00
|
|
|
#include "llvm/ADT/StringSet.h"
|
2019-05-13 09:00:22 -07:00
|
|
|
#include "llvm/ADT/Twine.h"
|
2018-06-22 22:03:48 -07:00
|
|
|
#include "llvm/Support/Allocator.h"
|
2020-04-03 19:02:39 -07:00
|
|
|
#include "llvm/Support/CommandLine.h"
|
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 ®istry) 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
|
|
|
#include "llvm/Support/Debug.h"
|
2021-11-11 01:44:58 +00:00
|
|
|
#include "llvm/Support/Mutex.h"
|
2019-03-12 10:00:21 -07:00
|
|
|
#include "llvm/Support/RWMutex.h"
|
2021-06-23 01:16:55 +00:00
|
|
|
#include "llvm/Support/ThreadPool.h"
|
2018-08-01 10:18:59 -07:00
|
|
|
#include "llvm/Support/raw_ostream.h"
|
2018-10-21 19:49:31 -07:00
|
|
|
#include <memory>
|
2018-09-21 18:12:15 -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 ®istry) 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
|
|
|
#define DEBUG_TYPE "mlircontext"
|
|
|
|
|
2018-06-22 22:03:48 -07:00
|
|
|
using namespace mlir;
|
2018-10-08 10:20:25 -07:00
|
|
|
using namespace mlir::detail;
|
2019-04-27 18:35:04 -07:00
|
|
|
|
2020-04-11 23:11:51 -07:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// MLIRContext CommandLine Options
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
namespace {
|
|
|
|
/// This struct contains command line options that can be used to initialize
|
|
|
|
/// various bits of an MLIRContext. This uses a struct wrapper to avoid the need
|
|
|
|
/// for global command line options.
|
|
|
|
struct MLIRContextOptions {
|
2020-05-02 12:28:57 -07:00
|
|
|
llvm::cl::opt<bool> disableThreading{
|
|
|
|
"mlir-disable-threading",
|
2021-09-15 01:38:38 +00:00
|
|
|
llvm::cl::desc("Disable multi-threading within MLIR, overrides any "
|
|
|
|
"further call to MLIRContext::enableMultiThreading()")};
|
2020-05-02 12:28:57 -07:00
|
|
|
|
2020-04-11 23:11:51 -07:00
|
|
|
llvm::cl::opt<bool> printOpOnDiagnostic{
|
|
|
|
"mlir-print-op-on-diagnostic",
|
|
|
|
llvm::cl::desc("When a diagnostic is emitted on an operation, also print "
|
|
|
|
"the operation as an attached note"),
|
|
|
|
llvm::cl::init(true)};
|
|
|
|
|
|
|
|
llvm::cl::opt<bool> printStackTraceOnDiagnostic{
|
|
|
|
"mlir-print-stacktrace-on-diagnostic",
|
|
|
|
llvm::cl::desc("When a diagnostic is emitted, also print the stack trace "
|
|
|
|
"as an attached note")};
|
|
|
|
};
|
2021-12-07 18:27:58 +00:00
|
|
|
} // namespace
|
2020-04-11 23:11:51 -07:00
|
|
|
|
|
|
|
static llvm::ManagedStatic<MLIRContextOptions> clOptions;
|
|
|
|
|
2021-09-15 01:38:38 +00:00
|
|
|
static bool isThreadingGloballyDisabled() {
|
|
|
|
#if LLVM_ENABLE_THREADS != 0
|
|
|
|
return clOptions.isConstructed() && clOptions->disableThreading;
|
|
|
|
#else
|
|
|
|
return true;
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
2020-04-11 23:11:51 -07:00
|
|
|
/// Register a set of useful command-line options that can be used to configure
|
|
|
|
/// various flags within the MLIRContext. These flags are used when constructing
|
|
|
|
/// an MLIR context for initialization.
|
|
|
|
void mlir::registerMLIRContextCLOptions() {
|
|
|
|
// Make sure that the options struct has been initialized.
|
|
|
|
*clOptions;
|
|
|
|
}
|
2020-04-03 19:02:39 -07:00
|
|
|
|
2020-05-02 12:28:57 -07:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// Locking Utilities
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
namespace {
|
|
|
|
/// Utility writer lock that takes a runtime flag that specifies if we really
|
|
|
|
/// need to lock.
|
|
|
|
struct ScopedWriterLock {
|
|
|
|
ScopedWriterLock(llvm::sys::SmartRWMutex<true> &mutexParam, bool shouldLock)
|
|
|
|
: mutex(shouldLock ? &mutexParam : nullptr) {
|
|
|
|
if (mutex)
|
|
|
|
mutex->lock();
|
|
|
|
}
|
|
|
|
~ScopedWriterLock() {
|
|
|
|
if (mutex)
|
|
|
|
mutex->unlock();
|
|
|
|
}
|
|
|
|
llvm::sys::SmartRWMutex<true> *mutex;
|
|
|
|
};
|
2021-12-07 18:27:58 +00:00
|
|
|
} // namespace
|
2020-05-02 12:28:57 -07:00
|
|
|
|
2020-04-11 23:11:51 -07:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// MLIRContextImpl
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2018-06-22 22:03:48 -07:00
|
|
|
namespace mlir {
|
|
|
|
/// This is the implementation of the MLIRContext class, using the pImpl idiom.
|
|
|
|
/// This class is completely private to this file, so everything is public.
|
|
|
|
class MLIRContextImpl {
|
|
|
|
public:
|
[mlir] Add a new debug action framework.
This revision adds the infrastructure for `Debug Actions`. This is a DEBUG only
API that allows for external entities to control various aspects of compiler
execution. This is conceptually similar to something like DebugCounters in LLVM, but at a lower level. This framework doesn't make any assumptions about how the higher level driver is controlling the execution, it merely provides a framework for connecting the two together. This means that on top of DebugCounter functionality, we could also provide more interesting drivers such as interactive execution. A high level overview of the workflow surrounding debug actions is
shown below:
* Compiler developer defines an `action` that is taken by the a pass,
transformation, utility that they are developing.
* Depending on the needs, the developer dispatches various queries, pertaining
to this action, to an `action manager` that will provide an answer as to
what behavior the action should do.
* An external entity registers an `action handler` with the action manager,
and provides the logic to resolve queries on actions.
The exact definition of an `external entity` is left opaque, to allow for more
interesting handlers.
This framework was proposed here: https://llvm.discourse.group/t/rfc-debug-actions-in-mlir-debug-counters-for-the-modern-world
Differential Revision: https://reviews.llvm.org/D84986
2021-02-23 00:51:49 -08:00
|
|
|
//===--------------------------------------------------------------------===//
|
|
|
|
// Debugging
|
|
|
|
//===--------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
/// An action manager for use within the context.
|
|
|
|
DebugActionManager debugActionManager;
|
|
|
|
|
2019-05-01 11:14:15 -07:00
|
|
|
//===--------------------------------------------------------------------===//
|
|
|
|
// Diagnostics
|
|
|
|
//===--------------------------------------------------------------------===//
|
|
|
|
DiagnosticEngine diagEngine;
|
|
|
|
|
2020-03-29 22:35:38 +00:00
|
|
|
//===--------------------------------------------------------------------===//
|
|
|
|
// Options
|
|
|
|
//===--------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
/// In most cases, creating operation in unregistered dialect is not desired
|
|
|
|
/// and indicate a misconfiguration of the compiler. This option enables to
|
|
|
|
/// detect such use cases
|
|
|
|
bool allowUnregisteredDialects = false;
|
|
|
|
|
2020-05-02 12:28:57 -07:00
|
|
|
/// Enable support for multi-threading within MLIR.
|
|
|
|
bool threadingIsEnabled = true;
|
|
|
|
|
2020-08-24 05:03:59 +00:00
|
|
|
/// Track if we are currently executing in a threaded execution environment
|
|
|
|
/// (like the pass-manager): this is only a debugging feature to help reducing
|
|
|
|
/// the chances of data races one some context APIs.
|
|
|
|
#ifndef NDEBUG
|
|
|
|
std::atomic<int> multiThreadedExecutionContext{0};
|
|
|
|
#endif
|
|
|
|
|
2020-04-03 19:02:39 -07:00
|
|
|
/// If the operation should be attached to diagnostics printed via the
|
|
|
|
/// Operation::emit methods.
|
2020-04-11 23:11:51 -07:00
|
|
|
bool printOpOnDiagnostic = true;
|
2020-04-03 19:02:39 -07:00
|
|
|
|
|
|
|
/// If the current stack trace should be attached when emitting diagnostics.
|
2020-04-11 23:11:51 -07:00
|
|
|
bool printStackTraceOnDiagnostic = false;
|
2020-04-03 19:02:39 -07:00
|
|
|
|
2019-03-14 14:14:00 -07:00
|
|
|
//===--------------------------------------------------------------------===//
|
|
|
|
// Other
|
|
|
|
//===--------------------------------------------------------------------===//
|
|
|
|
|
2021-07-01 20:57:53 +00:00
|
|
|
/// This points to the ThreadPool used when processing MLIR tasks in parallel.
|
|
|
|
/// It can't be nullptr when multi-threading is enabled. Otherwise if
|
|
|
|
/// multi-threading is disabled, and the threadpool wasn't externally provided
|
|
|
|
/// using `setThreadPool`, this will be nullptr.
|
|
|
|
llvm::ThreadPool *threadPool = nullptr;
|
|
|
|
|
|
|
|
/// In case where the thread pool is owned by the context, this ensures
|
|
|
|
/// destruction with the context.
|
|
|
|
std::unique_ptr<llvm::ThreadPool> ownedThreadPool;
|
2021-06-23 01:16:55 +00:00
|
|
|
|
2018-10-21 19:49:31 -07:00
|
|
|
/// This is a list of dialects that are created referring to this context.
|
|
|
|
/// The MLIRContext owns the objects.
|
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 ®istry) 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
|
|
|
DenseMap<StringRef, std::unique_ptr<Dialect>> loadedDialects;
|
|
|
|
DialectRegistry dialectsRegistry;
|
2018-10-21 19:49:31 -07:00
|
|
|
|
2020-06-30 15:42:39 -07:00
|
|
|
/// An allocator used for AbstractAttribute and AbstractType objects.
|
|
|
|
llvm::BumpPtrAllocator abstractDialectSymbolAllocator;
|
|
|
|
|
2021-11-17 21:50:28 +00:00
|
|
|
/// This is a mapping from operation name to the operation info describing it.
|
|
|
|
llvm::StringMap<OperationName::Impl> operations;
|
|
|
|
|
|
|
|
/// A vector of operation info specifically for registered operations.
|
2022-01-12 23:46:59 -08:00
|
|
|
llvm::StringMap<RegisteredOperationName> registeredOperations;
|
2021-11-17 21:50:28 +00:00
|
|
|
|
2022-02-03 13:16:14 -08:00
|
|
|
/// This is a sorted container of registered operations for a deterministic
|
|
|
|
/// and efficient `getRegisteredOperations` implementation.
|
|
|
|
SmallVector<RegisteredOperationName, 0> sortedRegisteredOperations;
|
|
|
|
|
2021-11-17 21:50:28 +00:00
|
|
|
/// A mutex used when accessing operation information.
|
|
|
|
llvm::sys::SmartRWMutex<true> operationInfoMutex;
|
|
|
|
|
2019-03-14 14:13:45 -07:00
|
|
|
//===--------------------------------------------------------------------===//
|
|
|
|
// Affine uniquing
|
|
|
|
//===--------------------------------------------------------------------===//
|
|
|
|
|
2021-12-02 23:49:02 +01:00
|
|
|
// Affine expression, map and integer set uniquing.
|
2019-05-21 01:34:13 -07:00
|
|
|
StorageUniquer affineUniquer;
|
2018-07-24 22:34:09 -07:00
|
|
|
|
2019-03-14 14:13:45 -07:00
|
|
|
//===--------------------------------------------------------------------===//
|
|
|
|
// Type uniquing
|
|
|
|
//===--------------------------------------------------------------------===//
|
2020-06-30 15:42:39 -07:00
|
|
|
|
2021-06-14 17:26:17 +02:00
|
|
|
DenseMap<TypeID, AbstractType *> registeredTypes;
|
2019-04-25 21:01:21 -07:00
|
|
|
StorageUniquer typeUniquer;
|
2018-07-16 09:45:22 -07:00
|
|
|
|
2019-06-21 09:20:42 -07:00
|
|
|
/// Cached Type Instances.
|
2020-08-12 19:28:54 -07:00
|
|
|
BFloat16Type bf16Ty;
|
|
|
|
Float16Type f16Ty;
|
|
|
|
Float32Type f32Ty;
|
|
|
|
Float64Type f64Ty;
|
2021-01-15 10:29:37 -05:00
|
|
|
Float80Type f80Ty;
|
|
|
|
Float128Type f128Ty;
|
2019-06-21 09:20:42 -07:00
|
|
|
IndexType indexTy;
|
|
|
|
IntegerType int1Ty, int8Ty, int16Ty, int32Ty, int64Ty, int128Ty;
|
|
|
|
NoneType noneType;
|
|
|
|
|
2019-03-14 14:13:45 -07:00
|
|
|
//===--------------------------------------------------------------------===//
|
|
|
|
// Attribute uniquing
|
|
|
|
//===--------------------------------------------------------------------===//
|
2020-06-30 15:42:39 -07:00
|
|
|
|
2021-06-14 17:26:17 +02:00
|
|
|
DenseMap<TypeID, AbstractAttribute *> registeredAttributes;
|
2019-04-30 10:31:29 -07:00
|
|
|
StorageUniquer attributeUniquer;
|
2019-03-14 14:13:29 -07:00
|
|
|
|
2019-06-21 09:20:42 -07:00
|
|
|
/// Cached Attribute Instances.
|
|
|
|
BoolAttr falseAttr, trueAttr;
|
|
|
|
UnitAttr unitAttr;
|
2019-06-21 18:27:49 -07:00
|
|
|
UnknownLoc unknownLocAttr;
|
2020-05-06 13:48:36 -07:00
|
|
|
DictionaryAttr emptyDictionaryAttr;
|
2021-05-25 14:38:01 -07:00
|
|
|
StringAttr emptyStringAttr;
|
2019-06-21 09:20:42 -07:00
|
|
|
|
2021-11-11 01:44:58 +00:00
|
|
|
/// Map of string attributes that may reference a dialect, that are awaiting
|
|
|
|
/// that dialect to be loaded.
|
|
|
|
llvm::sys::SmartMutex<true> dialectRefStrAttrMutex;
|
|
|
|
DenseMap<StringRef, SmallVector<StringAttrStorage *>>
|
|
|
|
dialectReferencingStrAttrs;
|
|
|
|
|
2018-06-22 22:03:48 -07:00
|
|
|
public:
|
2021-07-01 20:57:53 +00:00
|
|
|
MLIRContextImpl(bool threadingIsEnabled)
|
2021-11-11 01:44:58 +00:00
|
|
|
: threadingIsEnabled(threadingIsEnabled) {
|
2021-07-01 20:57:53 +00:00
|
|
|
if (threadingIsEnabled) {
|
|
|
|
ownedThreadPool = std::make_unique<llvm::ThreadPool>();
|
|
|
|
threadPool = ownedThreadPool.get();
|
|
|
|
}
|
2021-06-28 13:15:24 -07:00
|
|
|
}
|
2020-07-11 20:05:28 +00:00
|
|
|
~MLIRContextImpl() {
|
|
|
|
for (auto typeMapping : registeredTypes)
|
|
|
|
typeMapping.second->~AbstractType();
|
|
|
|
for (auto attrMapping : registeredAttributes)
|
|
|
|
attrMapping.second->~AbstractAttribute();
|
|
|
|
}
|
2018-06-22 22:03:48 -07:00
|
|
|
};
|
2021-12-07 18:27:58 +00:00
|
|
|
} // namespace mlir
|
2018-06-22 22:03:48 -07:00
|
|
|
|
2021-07-01 20:57:53 +00:00
|
|
|
MLIRContext::MLIRContext(Threading setting)
|
|
|
|
: MLIRContext(DialectRegistry(), setting) {}
|
2021-02-10 10:11:50 +01:00
|
|
|
|
2021-07-01 20:57:53 +00:00
|
|
|
MLIRContext::MLIRContext(const DialectRegistry ®istry, Threading setting)
|
2021-09-15 01:38:38 +00:00
|
|
|
: impl(new MLIRContextImpl(setting == Threading::ENABLED &&
|
|
|
|
!isThreadingGloballyDisabled())) {
|
2020-05-02 12:28:57 -07:00
|
|
|
// Initialize values based on the command line flags if they were provided.
|
|
|
|
if (clOptions.isConstructed()) {
|
|
|
|
printOpOnDiagnostic(clOptions->printOpOnDiagnostic);
|
|
|
|
printStackTraceOnDiagnostic(clOptions->printStackTraceOnDiagnostic);
|
|
|
|
}
|
|
|
|
|
2021-02-10 10:11:50 +01:00
|
|
|
// Pre-populate the registry.
|
|
|
|
registry.appendTo(impl->dialectsRegistry);
|
|
|
|
|
2021-06-16 18:53:21 +02:00
|
|
|
// Ensure the builtin dialect is always pre-loaded.
|
|
|
|
getOrLoadDialect<BuiltinDialect>();
|
|
|
|
|
2019-06-21 09:20:42 -07:00
|
|
|
// Initialize several common attributes and types to avoid the need to lock
|
|
|
|
// the context when accessing them.
|
|
|
|
|
|
|
|
//// Types.
|
|
|
|
/// Floating-point Types.
|
2020-08-18 15:59:53 -07:00
|
|
|
impl->bf16Ty = TypeUniquer::get<BFloat16Type>(this);
|
|
|
|
impl->f16Ty = TypeUniquer::get<Float16Type>(this);
|
|
|
|
impl->f32Ty = TypeUniquer::get<Float32Type>(this);
|
|
|
|
impl->f64Ty = TypeUniquer::get<Float64Type>(this);
|
2021-01-15 10:29:37 -05:00
|
|
|
impl->f80Ty = TypeUniquer::get<Float80Type>(this);
|
|
|
|
impl->f128Ty = TypeUniquer::get<Float128Type>(this);
|
2019-06-21 09:20:42 -07:00
|
|
|
/// Index Type.
|
2020-08-18 15:59:53 -07:00
|
|
|
impl->indexTy = TypeUniquer::get<IndexType>(this);
|
2019-06-21 09:20:42 -07:00
|
|
|
/// Integer Types.
|
2020-08-18 15:59:53 -07:00
|
|
|
impl->int1Ty = TypeUniquer::get<IntegerType>(this, 1, IntegerType::Signless);
|
|
|
|
impl->int8Ty = TypeUniquer::get<IntegerType>(this, 8, IntegerType::Signless);
|
|
|
|
impl->int16Ty =
|
|
|
|
TypeUniquer::get<IntegerType>(this, 16, IntegerType::Signless);
|
|
|
|
impl->int32Ty =
|
|
|
|
TypeUniquer::get<IntegerType>(this, 32, IntegerType::Signless);
|
|
|
|
impl->int64Ty =
|
|
|
|
TypeUniquer::get<IntegerType>(this, 64, IntegerType::Signless);
|
|
|
|
impl->int128Ty =
|
|
|
|
TypeUniquer::get<IntegerType>(this, 128, IntegerType::Signless);
|
2019-06-21 09:20:42 -07:00
|
|
|
/// None Type.
|
2020-08-18 15:59:53 -07:00
|
|
|
impl->noneType = TypeUniquer::get<NoneType>(this);
|
2019-06-21 09:20:42 -07:00
|
|
|
|
|
|
|
//// Attributes.
|
|
|
|
//// Note: These must be registered after the types as they may generate one
|
|
|
|
//// of the above types internally.
|
2021-03-16 16:30:46 -07:00
|
|
|
/// Unknown Location Attribute.
|
|
|
|
impl->unknownLocAttr = AttributeUniquer::get<UnknownLoc>(this);
|
2019-06-21 09:20:42 -07:00
|
|
|
/// Bool Attributes.
|
2021-03-16 16:30:46 -07:00
|
|
|
impl->falseAttr = IntegerAttr::getBoolAttrUnchecked(impl->int1Ty, false);
|
|
|
|
impl->trueAttr = IntegerAttr::getBoolAttrUnchecked(impl->int1Ty, true);
|
2019-06-21 09:20:42 -07:00
|
|
|
/// Unit Attribute.
|
2020-08-18 15:59:53 -07:00
|
|
|
impl->unitAttr = AttributeUniquer::get<UnitAttr>(this);
|
2020-05-06 13:48:36 -07:00
|
|
|
/// The empty dictionary attribute.
|
2021-03-04 12:37:32 -08:00
|
|
|
impl->emptyDictionaryAttr = DictionaryAttr::getEmptyUnchecked(this);
|
2021-05-25 14:38:01 -07:00
|
|
|
/// The empty string attribute.
|
|
|
|
impl->emptyStringAttr = StringAttr::getEmptyStringAttrUnchecked(this);
|
2020-08-07 13:29:11 -07:00
|
|
|
|
|
|
|
// Register the affine storage objects with the uniquer.
|
2020-08-18 15:59:53 -07:00
|
|
|
impl->affineUniquer
|
|
|
|
.registerParametricStorageType<AffineBinaryOpExprStorage>();
|
|
|
|
impl->affineUniquer
|
|
|
|
.registerParametricStorageType<AffineConstantExprStorage>();
|
|
|
|
impl->affineUniquer.registerParametricStorageType<AffineDimExprStorage>();
|
2021-12-02 23:49:02 +01:00
|
|
|
impl->affineUniquer.registerParametricStorageType<AffineMapStorage>();
|
|
|
|
impl->affineUniquer.registerParametricStorageType<IntegerSetStorage>();
|
2018-09-21 18:12:15 -07:00
|
|
|
}
|
2018-06-22 22:03:48 -07:00
|
|
|
|
2021-12-22 00:19:53 +00:00
|
|
|
MLIRContext::~MLIRContext() = default;
|
2018-06-22 22:03:48 -07:00
|
|
|
|
2019-03-14 14:13:29 -07:00
|
|
|
/// Copy the specified array of elements into memory managed by the provided
|
|
|
|
/// bump pointer allocator. This assumes the elements are all PODs.
|
|
|
|
template <typename T>
|
|
|
|
static ArrayRef<T> copyArrayRefInto(llvm::BumpPtrAllocator &allocator,
|
|
|
|
ArrayRef<T> elements) {
|
|
|
|
auto result = allocator.Allocate<T>(elements.size());
|
|
|
|
std::uninitialized_copy(elements.begin(), elements.end(), result);
|
|
|
|
return ArrayRef<T>(result, elements.size());
|
|
|
|
}
|
|
|
|
|
[mlir] Add a new debug action framework.
This revision adds the infrastructure for `Debug Actions`. This is a DEBUG only
API that allows for external entities to control various aspects of compiler
execution. This is conceptually similar to something like DebugCounters in LLVM, but at a lower level. This framework doesn't make any assumptions about how the higher level driver is controlling the execution, it merely provides a framework for connecting the two together. This means that on top of DebugCounter functionality, we could also provide more interesting drivers such as interactive execution. A high level overview of the workflow surrounding debug actions is
shown below:
* Compiler developer defines an `action` that is taken by the a pass,
transformation, utility that they are developing.
* Depending on the needs, the developer dispatches various queries, pertaining
to this action, to an `action manager` that will provide an answer as to
what behavior the action should do.
* An external entity registers an `action handler` with the action manager,
and provides the logic to resolve queries on actions.
The exact definition of an `external entity` is left opaque, to allow for more
interesting handlers.
This framework was proposed here: https://llvm.discourse.group/t/rfc-debug-actions-in-mlir-debug-counters-for-the-modern-world
Differential Revision: https://reviews.llvm.org/D84986
2021-02-23 00:51:49 -08:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// Debugging
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
DebugActionManager &MLIRContext::getDebugActionManager() {
|
|
|
|
return getImpl().debugActionManager;
|
|
|
|
}
|
|
|
|
|
2018-10-21 19:49:31 -07:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// Diagnostic Handlers
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2019-05-01 11:14:15 -07:00
|
|
|
/// Returns the diagnostic engine for this context.
|
|
|
|
DiagnosticEngine &MLIRContext::getDiagEngine() { return getImpl().diagEngine; }
|
|
|
|
|
2018-10-21 19:49:31 -07:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// Dialect and Operation Registration
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2021-02-10 10:11:50 +01:00
|
|
|
void MLIRContext::appendDialectRegistry(const DialectRegistry ®istry) {
|
2022-01-18 16:16:54 -08:00
|
|
|
if (registry.isSubsetOf(impl->dialectsRegistry))
|
|
|
|
return;
|
|
|
|
|
|
|
|
assert(impl->multiThreadedExecutionContext == 0 &&
|
|
|
|
"appending to the MLIRContext dialect registry while in a "
|
|
|
|
"multi-threaded execution context");
|
2021-02-10 10:11:50 +01:00
|
|
|
registry.appendTo(impl->dialectsRegistry);
|
|
|
|
|
2022-02-22 14:49:12 -08:00
|
|
|
// For the already loaded dialects, apply any possible extensions immediately.
|
|
|
|
registry.applyExtensions(this);
|
2021-02-10 10:11:50 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
const DialectRegistry &MLIRContext::getDialectRegistry() {
|
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 ®istry) 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 impl->dialectsRegistry;
|
|
|
|
}
|
|
|
|
|
2018-10-25 16:44:04 -07:00
|
|
|
/// Return information about all registered IR dialects.
|
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 ®istry) 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::vector<Dialect *> MLIRContext::getLoadedDialects() {
|
2018-10-25 16:44:04 -07:00
|
|
|
std::vector<Dialect *> result;
|
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 ®istry) 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
|
|
|
result.reserve(impl->loadedDialects.size());
|
|
|
|
for (auto &dialect : impl->loadedDialects)
|
|
|
|
result.push_back(dialect.second.get());
|
|
|
|
llvm::array_pod_sort(result.begin(), result.end(),
|
|
|
|
[](Dialect *const *lhs, Dialect *const *rhs) -> int {
|
|
|
|
return (*lhs)->getNamespace() < (*rhs)->getNamespace();
|
|
|
|
});
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
std::vector<StringRef> MLIRContext::getAvailableDialects() {
|
|
|
|
std::vector<StringRef> result;
|
2021-02-10 10:11:40 +01:00
|
|
|
for (auto dialect : impl->dialectsRegistry.getDialectNames())
|
|
|
|
result.push_back(dialect);
|
2018-10-25 16:44:04 -07:00
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
2019-01-02 09:26:35 -08:00
|
|
|
/// Get a registered IR dialect with the given namespace. If none is found,
|
|
|
|
/// then return nullptr.
|
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 ®istry) 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
|
|
|
Dialect *MLIRContext::getLoadedDialect(StringRef name) {
|
2020-05-02 12:28:57 -07:00
|
|
|
// Dialects are sorted by name, so we can use binary search for lookup.
|
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 ®istry) 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
|
|
|
auto it = impl->loadedDialects.find(name);
|
|
|
|
return (it != impl->loadedDialects.end()) ? it->second.get() : nullptr;
|
|
|
|
}
|
|
|
|
|
|
|
|
Dialect *MLIRContext::getOrLoadDialect(StringRef name) {
|
|
|
|
Dialect *dialect = getLoadedDialect(name);
|
|
|
|
if (dialect)
|
|
|
|
return dialect;
|
2021-02-10 10:11:50 +01:00
|
|
|
DialectAllocatorFunctionRef allocator =
|
|
|
|
impl->dialectsRegistry.getDialectAllocator(name);
|
|
|
|
return allocator ? allocator(this) : nullptr;
|
2018-11-20 14:47:10 -08:00
|
|
|
}
|
|
|
|
|
2020-08-07 02:41:44 +00:00
|
|
|
/// Get a dialect for the provided namespace and TypeID: abort the program if a
|
|
|
|
/// dialect exist for this namespace with different TypeID. Returns a pointer to
|
|
|
|
/// the dialect owned by the context.
|
|
|
|
Dialect *
|
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 ®istry) 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
|
|
|
MLIRContext::getOrLoadDialect(StringRef dialectNamespace, TypeID dialectID,
|
|
|
|
function_ref<std::unique_ptr<Dialect>()> ctor) {
|
2020-08-07 02:41:44 +00:00
|
|
|
auto &impl = getImpl();
|
2019-08-20 19:58:35 -07:00
|
|
|
// Get the correct insertion position sorted by namespace.
|
2021-12-16 01:19:56 +00:00
|
|
|
auto dialectIt = impl.loadedDialects.find(dialectNamespace);
|
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 ®istry) 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
|
|
|
|
2021-12-16 01:19:56 +00:00
|
|
|
if (dialectIt == impl.loadedDialects.end()) {
|
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 ®istry) 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
|
|
|
LLVM_DEBUG(llvm::dbgs()
|
2020-09-21 12:53:58 -07:00
|
|
|
<< "Load new dialect in Context " << dialectNamespace << "\n");
|
2020-08-24 05:03:59 +00:00
|
|
|
#ifndef NDEBUG
|
2020-08-29 00:34:59 +00:00
|
|
|
if (impl.multiThreadedExecutionContext != 0)
|
|
|
|
llvm::report_fatal_error(
|
|
|
|
"Loading a dialect (" + dialectNamespace +
|
|
|
|
") while in a multi-threaded execution context (maybe "
|
|
|
|
"the PassManager): this can indicate a "
|
|
|
|
"missing `dependentDialects` in a pass for example.");
|
2020-08-24 05:03:59 +00:00
|
|
|
#endif
|
2021-12-16 01:19:56 +00:00
|
|
|
std::unique_ptr<Dialect> &dialect =
|
|
|
|
impl.loadedDialects.insert({dialectNamespace, ctor()}).first->second;
|
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 ®istry) 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
|
|
|
assert(dialect && "dialect ctor failed");
|
2021-01-29 00:05:26 +00:00
|
|
|
|
|
|
|
// Refresh all the identifiers dialect field, this catches cases where a
|
|
|
|
// dialect may be loaded after identifier prefixed with this dialect name
|
|
|
|
// were already created.
|
2021-11-11 01:44:58 +00:00
|
|
|
auto stringAttrsIt = impl.dialectReferencingStrAttrs.find(dialectNamespace);
|
|
|
|
if (stringAttrsIt != impl.dialectReferencingStrAttrs.end()) {
|
|
|
|
for (StringAttrStorage *storage : stringAttrsIt->second)
|
|
|
|
storage->referencedDialect = dialect.get();
|
|
|
|
impl.dialectReferencingStrAttrs.erase(stringAttrsIt);
|
|
|
|
}
|
2021-01-29 00:05:26 +00:00
|
|
|
|
2022-02-22 14:49:12 -08:00
|
|
|
// Apply any extensions to this newly loaded dialect.
|
|
|
|
impl.dialectsRegistry.applyExtensions(dialect.get());
|
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 ®istry) 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 dialect.get();
|
|
|
|
}
|
2019-08-20 19:58:35 -07:00
|
|
|
|
2019-04-15 16:32:00 -07:00
|
|
|
// Abort if dialect with namespace has already been registered.
|
2021-12-16 01:19:56 +00:00
|
|
|
std::unique_ptr<Dialect> &dialect = dialectIt->second;
|
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 ®istry) 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
|
|
|
if (dialect->getTypeID() != dialectID)
|
2020-08-07 02:41:44 +00:00
|
|
|
llvm::report_fatal_error("a dialect with namespace '" + dialectNamespace +
|
2019-04-15 16:32:00 -07:00
|
|
|
"' has already been registered");
|
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 ®istry) 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 dialect.get();
|
2021-01-26 16:54:25 -08:00
|
|
|
}
|
|
|
|
|
2022-09-19 09:47:37 -07:00
|
|
|
DynamicDialect *MLIRContext::getOrLoadDynamicDialect(
|
|
|
|
StringRef dialectNamespace, function_ref<void(DynamicDialect *)> ctor) {
|
|
|
|
auto &impl = getImpl();
|
|
|
|
// Get the correct insertion position sorted by namespace.
|
|
|
|
auto dialectIt = impl.loadedDialects.find(dialectNamespace);
|
|
|
|
|
|
|
|
if (dialectIt != impl.loadedDialects.end()) {
|
|
|
|
if (auto dynDialect = dyn_cast<DynamicDialect>(dialectIt->second.get()))
|
|
|
|
return dynDialect;
|
|
|
|
llvm::report_fatal_error("a dialect with namespace '" + dialectNamespace +
|
|
|
|
"' has already been registered");
|
|
|
|
}
|
|
|
|
|
|
|
|
LLVM_DEBUG(llvm::dbgs() << "Load new dynamic dialect in Context "
|
|
|
|
<< dialectNamespace << "\n");
|
|
|
|
#ifndef NDEBUG
|
|
|
|
if (impl.multiThreadedExecutionContext != 0)
|
|
|
|
llvm::report_fatal_error(
|
|
|
|
"Loading a dynamic dialect (" + dialectNamespace +
|
|
|
|
") while in a multi-threaded execution context (maybe "
|
|
|
|
"the PassManager): this can indicate a "
|
|
|
|
"missing `dependentDialects` in a pass for example.");
|
|
|
|
#endif
|
|
|
|
|
|
|
|
auto name = StringAttr::get(this, dialectNamespace);
|
|
|
|
auto *dialect = new DynamicDialect(name, this);
|
|
|
|
(void)getOrLoadDialect(name, dialect->getTypeID(), [dialect, ctor]() {
|
|
|
|
ctor(dialect);
|
|
|
|
return std::unique_ptr<DynamicDialect>(dialect);
|
|
|
|
});
|
|
|
|
// This is the same result as `getOrLoadDialect` (if it didn't failed),
|
|
|
|
// since it has the same TypeID, and TypeIDs are unique.
|
|
|
|
return dialect;
|
|
|
|
}
|
|
|
|
|
2021-02-10 10:11:50 +01:00
|
|
|
void MLIRContext::loadAllAvailableDialects() {
|
|
|
|
for (StringRef name : getAvailableDialects())
|
|
|
|
getOrLoadDialect(name);
|
|
|
|
}
|
|
|
|
|
2021-01-26 16:54:25 -08:00
|
|
|
llvm::hash_code MLIRContext::getRegistryHash() {
|
|
|
|
llvm::hash_code hash(0);
|
|
|
|
// Factor in number of loaded dialects, attributes, operations, types.
|
|
|
|
hash = llvm::hash_combine(hash, impl->loadedDialects.size());
|
|
|
|
hash = llvm::hash_combine(hash, impl->registeredAttributes.size());
|
|
|
|
hash = llvm::hash_combine(hash, impl->registeredOperations.size());
|
|
|
|
hash = llvm::hash_combine(hash, impl->registeredTypes.size());
|
|
|
|
return hash;
|
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 ®istry) 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
|
|
|
}
|
|
|
|
|
2020-03-29 22:35:38 +00:00
|
|
|
bool MLIRContext::allowsUnregisteredDialects() {
|
|
|
|
return impl->allowUnregisteredDialects;
|
|
|
|
}
|
|
|
|
|
|
|
|
void MLIRContext::allowUnregisteredDialects(bool allowing) {
|
2022-01-18 16:16:54 -08:00
|
|
|
assert(impl->multiThreadedExecutionContext == 0 &&
|
|
|
|
"changing MLIRContext `allow-unregistered-dialects` configuration "
|
|
|
|
"while in a multi-threaded execution context");
|
2020-03-29 22:35:38 +00:00
|
|
|
impl->allowUnregisteredDialects = allowing;
|
|
|
|
}
|
|
|
|
|
2021-05-28 00:02:36 +00:00
|
|
|
/// Return true if multi-threading is enabled by the context.
|
2020-05-02 12:28:57 -07:00
|
|
|
bool MLIRContext::isMultithreadingEnabled() {
|
|
|
|
return impl->threadingIsEnabled && llvm::llvm_is_multithreaded();
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Set the flag specifying if multi-threading is disabled by the context.
|
|
|
|
void MLIRContext::disableMultithreading(bool disable) {
|
2021-09-15 01:38:38 +00:00
|
|
|
// This API can be overridden by the global debugging flag
|
|
|
|
// --mlir-disable-threading
|
|
|
|
if (isThreadingGloballyDisabled())
|
|
|
|
return;
|
2022-01-18 16:16:54 -08:00
|
|
|
assert(impl->multiThreadedExecutionContext == 0 &&
|
|
|
|
"changing MLIRContext `disable-threading` configuration while "
|
|
|
|
"in a multi-threaded execution context");
|
2021-09-15 01:38:38 +00:00
|
|
|
|
2020-05-02 12:28:57 -07:00
|
|
|
impl->threadingIsEnabled = !disable;
|
|
|
|
|
|
|
|
// Update the threading mode for each of the uniquers.
|
|
|
|
impl->affineUniquer.disableMultithreading(disable);
|
|
|
|
impl->attributeUniquer.disableMultithreading(disable);
|
|
|
|
impl->typeUniquer.disableMultithreading(disable);
|
2021-06-28 13:15:24 -07:00
|
|
|
|
|
|
|
// Destroy thread pool (stop all threads) if it is no longer needed, or create
|
|
|
|
// a new one if multithreading was re-enabled.
|
2021-07-01 20:57:53 +00:00
|
|
|
if (disable) {
|
|
|
|
// If the thread pool is owned, explicitly set it to nullptr to avoid
|
|
|
|
// keeping a dangling pointer around. If the thread pool is externally
|
|
|
|
// owned, we don't do anything.
|
|
|
|
if (impl->ownedThreadPool) {
|
|
|
|
assert(impl->threadPool);
|
|
|
|
impl->threadPool = nullptr;
|
|
|
|
impl->ownedThreadPool.reset();
|
|
|
|
}
|
|
|
|
} else if (!impl->threadPool) {
|
|
|
|
// The thread pool isn't externally provided.
|
|
|
|
assert(!impl->ownedThreadPool);
|
|
|
|
impl->ownedThreadPool = std::make_unique<llvm::ThreadPool>();
|
|
|
|
impl->threadPool = impl->ownedThreadPool.get();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void MLIRContext::setThreadPool(llvm::ThreadPool &pool) {
|
|
|
|
assert(!isMultithreadingEnabled() &&
|
|
|
|
"expected multi-threading to be disabled when setting a ThreadPool");
|
|
|
|
impl->threadPool = &pool;
|
|
|
|
impl->ownedThreadPool.reset();
|
|
|
|
enableMultithreading();
|
2020-05-02 12:28:57 -07:00
|
|
|
}
|
|
|
|
|
2021-12-24 01:41:21 +00:00
|
|
|
unsigned MLIRContext::getNumThreads() {
|
|
|
|
if (isMultithreadingEnabled()) {
|
|
|
|
assert(impl->threadPool &&
|
|
|
|
"multi-threading is enabled but threadpool not set");
|
|
|
|
return impl->threadPool->getThreadCount();
|
|
|
|
}
|
|
|
|
// No multithreading or active thread pool. Return 1 thread.
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2021-06-23 01:16:55 +00:00
|
|
|
llvm::ThreadPool &MLIRContext::getThreadPool() {
|
|
|
|
assert(isMultithreadingEnabled() &&
|
|
|
|
"expected multi-threading to be enabled within the context");
|
2021-07-01 20:57:53 +00:00
|
|
|
assert(impl->threadPool &&
|
|
|
|
"multi-threading is enabled but threadpool not set");
|
2021-06-28 13:15:24 -07:00
|
|
|
return *impl->threadPool;
|
2021-06-23 01:16:55 +00:00
|
|
|
}
|
|
|
|
|
2020-08-24 05:03:59 +00:00
|
|
|
void MLIRContext::enterMultiThreadedExecution() {
|
|
|
|
#ifndef NDEBUG
|
|
|
|
++impl->multiThreadedExecutionContext;
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
void MLIRContext::exitMultiThreadedExecution() {
|
|
|
|
#ifndef NDEBUG
|
|
|
|
--impl->multiThreadedExecutionContext;
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
2020-04-03 19:02:39 -07:00
|
|
|
/// Return true if we should attach the operation to diagnostics emitted via
|
|
|
|
/// Operation::emit.
|
|
|
|
bool MLIRContext::shouldPrintOpOnDiagnostic() {
|
|
|
|
return impl->printOpOnDiagnostic;
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Set the flag specifying if we should attach the operation to diagnostics
|
|
|
|
/// emitted via Operation::emit.
|
|
|
|
void MLIRContext::printOpOnDiagnostic(bool enable) {
|
2022-01-18 16:16:54 -08:00
|
|
|
assert(impl->multiThreadedExecutionContext == 0 &&
|
|
|
|
"changing MLIRContext `print-op-on-diagnostic` configuration while in "
|
|
|
|
"a multi-threaded execution context");
|
2020-04-11 23:11:51 -07:00
|
|
|
impl->printOpOnDiagnostic = enable;
|
2020-04-03 19:02:39 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
/// Return true if we should attach the current stacktrace to diagnostics when
|
|
|
|
/// emitted.
|
|
|
|
bool MLIRContext::shouldPrintStackTraceOnDiagnostic() {
|
|
|
|
return impl->printStackTraceOnDiagnostic;
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Set the flag specifying if we should attach the current stacktrace when
|
|
|
|
/// emitting diagnostics.
|
|
|
|
void MLIRContext::printStackTraceOnDiagnostic(bool enable) {
|
2022-01-18 16:16:54 -08:00
|
|
|
assert(impl->multiThreadedExecutionContext == 0 &&
|
|
|
|
"changing MLIRContext `print-stacktrace-on-diagnostic` configuration "
|
|
|
|
"while in a multi-threaded execution context");
|
2020-04-11 23:11:51 -07:00
|
|
|
impl->printStackTraceOnDiagnostic = enable;
|
2020-04-03 19:02:39 -07:00
|
|
|
}
|
|
|
|
|
2022-02-03 13:16:14 -08:00
|
|
|
/// Return information about all registered operations.
|
|
|
|
ArrayRef<RegisteredOperationName> MLIRContext::getRegisteredOperations() {
|
|
|
|
return impl->sortedRegisteredOperations;
|
2018-10-25 16:44:04 -07:00
|
|
|
}
|
|
|
|
|
2020-05-28 08:08:20 +00:00
|
|
|
bool MLIRContext::isOperationRegistered(StringRef name) {
|
2022-06-20 20:05:16 -07:00
|
|
|
return RegisteredOperationName::lookup(name, this).has_value();
|
2020-05-28 08:08:20 +00:00
|
|
|
}
|
|
|
|
|
2020-06-30 15:42:39 -07:00
|
|
|
void Dialect::addType(TypeID typeID, AbstractType &&typeInfo) {
|
2019-01-02 14:16:40 -08:00
|
|
|
auto &impl = context->getImpl();
|
2020-08-24 05:03:59 +00:00
|
|
|
assert(impl.multiThreadedExecutionContext == 0 &&
|
|
|
|
"Registering a new type kind while in a multi-threaded execution "
|
|
|
|
"context");
|
2020-06-30 15:42:39 -07:00
|
|
|
auto *newInfo =
|
|
|
|
new (impl.abstractDialectSymbolAllocator.Allocate<AbstractType>())
|
|
|
|
AbstractType(std::move(typeInfo));
|
|
|
|
if (!impl.registeredTypes.insert({typeID, newInfo}).second)
|
|
|
|
llvm::report_fatal_error("Dialect Type already registered.");
|
|
|
|
}
|
|
|
|
|
|
|
|
void Dialect::addAttribute(TypeID typeID, AbstractAttribute &&attrInfo) {
|
|
|
|
auto &impl = context->getImpl();
|
2020-08-24 05:03:59 +00:00
|
|
|
assert(impl.multiThreadedExecutionContext == 0 &&
|
|
|
|
"Registering a new attribute kind while in a multi-threaded execution "
|
|
|
|
"context");
|
2020-06-30 15:42:39 -07:00
|
|
|
auto *newInfo =
|
|
|
|
new (impl.abstractDialectSymbolAllocator.Allocate<AbstractAttribute>())
|
|
|
|
AbstractAttribute(std::move(attrInfo));
|
|
|
|
if (!impl.registeredAttributes.insert({typeID, newInfo}).second)
|
|
|
|
llvm::report_fatal_error("Dialect Attribute already registered.");
|
|
|
|
}
|
|
|
|
|
2020-11-02 14:21:02 -08:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// AbstractAttribute
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2020-06-30 15:42:39 -07:00
|
|
|
/// Get the dialect that registered the attribute with the provided typeid.
|
|
|
|
const AbstractAttribute &AbstractAttribute::lookup(TypeID typeID,
|
|
|
|
MLIRContext *context) {
|
2021-06-14 17:26:17 +02:00
|
|
|
const AbstractAttribute *abstract = lookupMutable(typeID, context);
|
|
|
|
if (!abstract)
|
|
|
|
llvm::report_fatal_error("Trying to create an Attribute that was not "
|
|
|
|
"registered in this MLIRContext.");
|
|
|
|
return *abstract;
|
|
|
|
}
|
|
|
|
|
|
|
|
AbstractAttribute *AbstractAttribute::lookupMutable(TypeID typeID,
|
|
|
|
MLIRContext *context) {
|
2020-06-30 15:42:39 -07:00
|
|
|
auto &impl = context->getImpl();
|
|
|
|
auto it = impl.registeredAttributes.find(typeID);
|
|
|
|
if (it == impl.registeredAttributes.end())
|
2021-06-14 17:26:17 +02:00
|
|
|
return nullptr;
|
|
|
|
return it->second;
|
2019-01-02 14:16:40 -08:00
|
|
|
}
|
|
|
|
|
2020-11-02 14:21:02 -08:00
|
|
|
//===----------------------------------------------------------------------===//
|
2021-11-17 21:50:28 +00:00
|
|
|
// OperationName
|
2020-11-02 14:21:02 -08:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2021-11-17 21:50:28 +00:00
|
|
|
OperationName::OperationName(StringRef name, MLIRContext *context) {
|
|
|
|
MLIRContextImpl &ctxImpl = context->getImpl();
|
|
|
|
|
|
|
|
// Check for an existing name in read-only mode.
|
|
|
|
bool isMultithreadingEnabled = context->isMultithreadingEnabled();
|
|
|
|
if (isMultithreadingEnabled) {
|
2022-01-12 23:46:59 -08:00
|
|
|
// Check the registered info map first. In the overwhelmingly common case,
|
|
|
|
// the entry will be in here and it also removes the need to acquire any
|
|
|
|
// locks.
|
|
|
|
auto registeredIt = ctxImpl.registeredOperations.find(name);
|
|
|
|
if (LLVM_LIKELY(registeredIt != ctxImpl.registeredOperations.end())) {
|
|
|
|
impl = registeredIt->second.impl;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2021-11-17 21:50:28 +00:00
|
|
|
llvm::sys::SmartScopedReader<true> contextLock(ctxImpl.operationInfoMutex);
|
|
|
|
auto it = ctxImpl.operations.find(name);
|
|
|
|
if (it != ctxImpl.operations.end()) {
|
|
|
|
impl = &it->second;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Acquire a writer-lock so that we can safely create the new instance.
|
|
|
|
ScopedWriterLock lock(ctxImpl.operationInfoMutex, isMultithreadingEnabled);
|
|
|
|
|
|
|
|
auto it = ctxImpl.operations.insert({name, OperationName::Impl(nullptr)});
|
|
|
|
if (it.second)
|
|
|
|
it.first->second.name = StringAttr::get(context, name);
|
|
|
|
impl = &it.first->second;
|
2020-11-02 14:21:02 -08:00
|
|
|
}
|
|
|
|
|
2021-11-17 21:50:28 +00:00
|
|
|
StringRef OperationName::getDialectNamespace() const {
|
|
|
|
if (Dialect *dialect = getDialect())
|
|
|
|
return dialect->getNamespace();
|
|
|
|
return getStringRef().split('.').first;
|
|
|
|
}
|
|
|
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// RegisteredOperationName
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2022-01-12 23:46:59 -08:00
|
|
|
Optional<RegisteredOperationName>
|
|
|
|
RegisteredOperationName::lookup(StringRef name, MLIRContext *ctx) {
|
|
|
|
auto &impl = ctx->getImpl();
|
|
|
|
auto it = impl.registeredOperations.find(name);
|
|
|
|
if (it != impl.registeredOperations.end())
|
|
|
|
return it->getValue();
|
|
|
|
return llvm::None;
|
|
|
|
}
|
|
|
|
|
2021-11-17 21:50:28 +00:00
|
|
|
ParseResult
|
|
|
|
RegisteredOperationName::parseAssembly(OpAsmParser &parser,
|
|
|
|
OperationState &result) const {
|
|
|
|
return impl->parseAssemblyFn(parser, result);
|
2018-07-05 09:12:11 -07:00
|
|
|
}
|
2018-06-22 22:03:48 -07:00
|
|
|
|
2022-07-08 11:31:12 -07:00
|
|
|
void RegisteredOperationName::populateDefaultAttrs(NamedAttrList &attrs) const {
|
|
|
|
impl->populateDefaultAttrsFn(*this, attrs);
|
|
|
|
}
|
|
|
|
|
2021-11-17 21:50:28 +00:00
|
|
|
void RegisteredOperationName::insert(
|
2021-02-09 11:41:10 -08:00
|
|
|
StringRef name, Dialect &dialect, TypeID typeID,
|
2021-05-25 11:36:04 -07:00
|
|
|
ParseAssemblyFn &&parseAssembly, PrintAssemblyFn &&printAssembly,
|
2022-02-25 18:17:30 +00:00
|
|
|
VerifyInvariantsFn &&verifyInvariants,
|
|
|
|
VerifyRegionInvariantsFn &&verifyRegionInvariants, FoldHookFn &&foldHook,
|
2021-05-25 11:36:04 -07:00
|
|
|
GetCanonicalizationPatternsFn &&getCanonicalizationPatterns,
|
2021-06-22 19:13:35 +00:00
|
|
|
detail::InterfaceMap &&interfaceMap, HasTraitFn &&hasTrait,
|
2022-07-08 11:31:12 -07:00
|
|
|
ArrayRef<StringRef> attrNames,
|
|
|
|
PopulateDefaultAttrsFn &&populateDefaultAttrs) {
|
2021-06-22 19:13:35 +00:00
|
|
|
MLIRContext *ctx = dialect.getContext();
|
2021-11-17 21:50:28 +00:00
|
|
|
auto &ctxImpl = ctx->getImpl();
|
|
|
|
assert(ctxImpl.multiThreadedExecutionContext == 0 &&
|
|
|
|
"registering a new operation kind while in a multi-threaded execution "
|
2020-11-02 14:21:02 -08:00
|
|
|
"context");
|
2021-06-22 19:13:35 +00:00
|
|
|
|
|
|
|
// Register the attribute names of this operation.
|
2021-11-16 17:21:15 +00:00
|
|
|
MutableArrayRef<StringAttr> cachedAttrNames;
|
2021-06-22 19:13:35 +00:00
|
|
|
if (!attrNames.empty()) {
|
2021-11-16 17:21:15 +00:00
|
|
|
cachedAttrNames = MutableArrayRef<StringAttr>(
|
2021-11-17 21:50:28 +00:00
|
|
|
ctxImpl.abstractDialectSymbolAllocator.Allocate<StringAttr>(
|
2021-11-11 01:44:58 +00:00
|
|
|
attrNames.size()),
|
2021-06-22 19:13:35 +00:00
|
|
|
attrNames.size());
|
|
|
|
for (unsigned i : llvm::seq<unsigned>(0, attrNames.size()))
|
2021-11-16 17:21:15 +00:00
|
|
|
new (&cachedAttrNames[i]) StringAttr(StringAttr::get(ctx, attrNames[i]));
|
2021-06-22 19:13:35 +00:00
|
|
|
}
|
|
|
|
|
2021-11-17 21:50:28 +00:00
|
|
|
// Insert the operation info if it doesn't exist yet.
|
|
|
|
auto it = ctxImpl.operations.insert({name, OperationName::Impl(nullptr)});
|
|
|
|
if (it.second)
|
|
|
|
it.first->second.name = StringAttr::get(ctx, name);
|
|
|
|
OperationName::Impl &impl = it.first->second;
|
|
|
|
|
|
|
|
if (impl.isRegistered()) {
|
2020-11-02 14:21:02 -08:00
|
|
|
llvm::errs() << "error: operation named '" << name
|
|
|
|
<< "' is already registered.\n";
|
|
|
|
abort();
|
|
|
|
}
|
2022-02-03 13:16:14 -08:00
|
|
|
auto emplaced = ctxImpl.registeredOperations.try_emplace(
|
|
|
|
name, RegisteredOperationName(&impl));
|
|
|
|
assert(emplaced.second && "operation name registration must be successful");
|
|
|
|
|
|
|
|
// Add emplaced operation name to the sorted operations container.
|
|
|
|
RegisteredOperationName &value = emplaced.first->getValue();
|
|
|
|
ctxImpl.sortedRegisteredOperations.insert(
|
|
|
|
llvm::upper_bound(ctxImpl.sortedRegisteredOperations, value,
|
|
|
|
[](auto &lhs, auto &rhs) {
|
|
|
|
return lhs.getIdentifier().compare(
|
|
|
|
rhs.getIdentifier());
|
|
|
|
}),
|
|
|
|
value);
|
2021-11-17 21:50:28 +00:00
|
|
|
|
|
|
|
// Update the registered info for this operation.
|
|
|
|
impl.dialect = &dialect;
|
|
|
|
impl.typeID = typeID;
|
|
|
|
impl.interfaceMap = std::move(interfaceMap);
|
|
|
|
impl.foldHookFn = std::move(foldHook);
|
|
|
|
impl.getCanonicalizationPatternsFn = std::move(getCanonicalizationPatterns);
|
|
|
|
impl.hasTraitFn = std::move(hasTrait);
|
|
|
|
impl.parseAssemblyFn = std::move(parseAssembly);
|
|
|
|
impl.printAssemblyFn = std::move(printAssembly);
|
|
|
|
impl.verifyInvariantsFn = std::move(verifyInvariants);
|
2022-02-25 18:17:30 +00:00
|
|
|
impl.verifyRegionInvariantsFn = std::move(verifyRegionInvariants);
|
2021-11-17 21:50:28 +00:00
|
|
|
impl.attributeNames = cachedAttrNames;
|
2022-07-08 11:31:12 -07:00
|
|
|
impl.populateDefaultAttrsFn = std::move(populateDefaultAttrs);
|
2020-11-02 14:21:02 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// AbstractType
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2020-06-30 15:42:39 -07:00
|
|
|
const AbstractType &AbstractType::lookup(TypeID typeID, MLIRContext *context) {
|
2021-06-14 17:26:17 +02:00
|
|
|
const AbstractType *type = lookupMutable(typeID, context);
|
|
|
|
if (!type)
|
|
|
|
llvm::report_fatal_error(
|
|
|
|
"Trying to create a Type that was not registered in this MLIRContext.");
|
|
|
|
return *type;
|
|
|
|
}
|
|
|
|
|
|
|
|
AbstractType *AbstractType::lookupMutable(TypeID typeID, MLIRContext *context) {
|
2020-06-30 15:42:39 -07:00
|
|
|
auto &impl = context->getImpl();
|
|
|
|
auto it = impl.registeredTypes.find(typeID);
|
|
|
|
if (it == impl.registeredTypes.end())
|
2021-06-14 17:26:17 +02:00
|
|
|
return nullptr;
|
|
|
|
return it->second;
|
2020-06-30 15:42:39 -07:00
|
|
|
}
|
|
|
|
|
2018-06-28 20:45:33 -07:00
|
|
|
//===----------------------------------------------------------------------===//
|
2018-07-04 10:43:29 -07:00
|
|
|
// Type uniquing
|
2018-06-28 20:45:33 -07:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
[mlir] NFC: fix trivial typo in source files
Summary: fix trivial typos in the source files
Reviewers: mravishankar, antiagainst, nicolasvasilache, herhut, rriddle, aartbik
Reviewed By: antiagainst, rriddle
Subscribers: mehdi_amini, rriddle, jpienaar, burmako, shauheen, antiagainst, nicolasvasilache, csigg, arpith-jacob, mgester, lucyrfox, aartbik, liufengdb, Joonsoo, bader, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D76876
2020-03-27 03:51:37 +09:00
|
|
|
/// Returns the storage uniquer used for constructing type storage instances.
|
2019-04-25 21:01:21 -07:00
|
|
|
/// This should not be used directly.
|
|
|
|
StorageUniquer &MLIRContext::getTypeUniquer() { return getImpl().typeUniquer; }
|
2018-12-21 10:18:03 -08:00
|
|
|
|
2020-08-12 19:28:54 -07:00
|
|
|
BFloat16Type BFloat16Type::get(MLIRContext *context) {
|
|
|
|
return context->getImpl().bf16Ty;
|
|
|
|
}
|
|
|
|
Float16Type Float16Type::get(MLIRContext *context) {
|
|
|
|
return context->getImpl().f16Ty;
|
|
|
|
}
|
|
|
|
Float32Type Float32Type::get(MLIRContext *context) {
|
|
|
|
return context->getImpl().f32Ty;
|
|
|
|
}
|
|
|
|
Float64Type Float64Type::get(MLIRContext *context) {
|
|
|
|
return context->getImpl().f64Ty;
|
2019-06-21 09:20:42 -07:00
|
|
|
}
|
2021-01-15 10:29:37 -05:00
|
|
|
Float80Type Float80Type::get(MLIRContext *context) {
|
|
|
|
return context->getImpl().f80Ty;
|
|
|
|
}
|
|
|
|
Float128Type Float128Type::get(MLIRContext *context) {
|
|
|
|
return context->getImpl().f128Ty;
|
|
|
|
}
|
2019-06-21 09:20:42 -07:00
|
|
|
|
|
|
|
/// Get an instance of the IndexType.
|
|
|
|
IndexType IndexType::get(MLIRContext *context) {
|
|
|
|
return context->getImpl().indexTy;
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Return an existing integer type instance if one is cached within the
|
|
|
|
/// context.
|
2020-01-10 14:48:24 -05:00
|
|
|
static IntegerType
|
|
|
|
getCachedIntegerType(unsigned width,
|
|
|
|
IntegerType::SignednessSemantics signedness,
|
|
|
|
MLIRContext *context) {
|
|
|
|
if (signedness != IntegerType::Signless)
|
|
|
|
return IntegerType();
|
|
|
|
|
2019-06-21 09:20:42 -07:00
|
|
|
switch (width) {
|
|
|
|
case 1:
|
|
|
|
return context->getImpl().int1Ty;
|
|
|
|
case 8:
|
|
|
|
return context->getImpl().int8Ty;
|
|
|
|
case 16:
|
|
|
|
return context->getImpl().int16Ty;
|
|
|
|
case 32:
|
|
|
|
return context->getImpl().int32Ty;
|
|
|
|
case 64:
|
|
|
|
return context->getImpl().int64Ty;
|
|
|
|
case 128:
|
|
|
|
return context->getImpl().int128Ty;
|
|
|
|
default:
|
|
|
|
return IntegerType();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-12-17 12:24:45 -08:00
|
|
|
IntegerType IntegerType::get(MLIRContext *context, unsigned width,
|
|
|
|
IntegerType::SignednessSemantics signedness) {
|
2020-01-10 14:48:24 -05:00
|
|
|
if (auto cached = getCachedIntegerType(width, signedness, context))
|
2019-06-21 09:20:42 -07:00
|
|
|
return cached;
|
2020-08-18 15:59:53 -07:00
|
|
|
return Base::get(context, width, signedness);
|
2020-01-10 14:48:24 -05:00
|
|
|
}
|
|
|
|
|
2021-02-22 17:30:19 -08:00
|
|
|
IntegerType
|
|
|
|
IntegerType::getChecked(function_ref<InFlightDiagnostic()> emitError,
|
|
|
|
MLIRContext *context, unsigned width,
|
|
|
|
SignednessSemantics signedness) {
|
|
|
|
if (auto cached = getCachedIntegerType(width, signedness, context))
|
2019-06-21 09:20:42 -07:00
|
|
|
return cached;
|
2021-02-22 17:30:19 -08:00
|
|
|
return Base::getChecked(emitError, context, width, signedness);
|
2019-06-21 09:20:42 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
/// Get an instance of the NoneType.
|
|
|
|
NoneType NoneType::get(MLIRContext *context) {
|
2020-08-18 15:59:53 -07:00
|
|
|
if (NoneType cachedInst = context->getImpl().noneType)
|
|
|
|
return cachedInst;
|
|
|
|
// Note: May happen when initializing the singleton attributes of the builtin
|
|
|
|
// dialect.
|
|
|
|
return Base::get(context);
|
2019-06-21 09:20:42 -07:00
|
|
|
}
|
|
|
|
|
2018-07-04 10:43:29 -07:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// Attribute uniquing
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2019-04-30 10:31:29 -07:00
|
|
|
/// Returns the storage uniquer used for constructing attribute storage
|
|
|
|
/// instances. This should not be used directly.
|
|
|
|
StorageUniquer &MLIRContext::getAttributeUniquer() {
|
|
|
|
return getImpl().attributeUniquer;
|
2018-08-19 21:17:22 -07:00
|
|
|
}
|
|
|
|
|
2020-04-11 23:00:11 -07:00
|
|
|
/// Initialize the given attribute storage instance.
|
|
|
|
void AttributeUniquer::initializeAttributeStorage(AttributeStorage *storage,
|
|
|
|
MLIRContext *ctx,
|
|
|
|
TypeID attrID) {
|
2021-11-11 01:44:58 +00:00
|
|
|
storage->initializeAbstractAttribute(AbstractAttribute::lookup(attrID, ctx));
|
2019-05-10 15:14:13 -07:00
|
|
|
}
|
|
|
|
|
2021-02-08 09:44:03 +01:00
|
|
|
BoolAttr BoolAttr::get(MLIRContext *context, bool value) {
|
2019-06-21 09:20:42 -07:00
|
|
|
return value ? context->getImpl().trueAttr : context->getImpl().falseAttr;
|
|
|
|
}
|
|
|
|
|
|
|
|
UnitAttr UnitAttr::get(MLIRContext *context) {
|
|
|
|
return context->getImpl().unitAttr;
|
|
|
|
}
|
|
|
|
|
2021-03-08 14:25:38 -08:00
|
|
|
UnknownLoc UnknownLoc::get(MLIRContext *context) {
|
2019-06-21 18:27:49 -07:00
|
|
|
return context->getImpl().unknownLocAttr;
|
|
|
|
}
|
|
|
|
|
2020-05-06 13:48:36 -07:00
|
|
|
/// Return empty dictionary.
|
|
|
|
DictionaryAttr DictionaryAttr::getEmpty(MLIRContext *context) {
|
|
|
|
return context->getImpl().emptyDictionaryAttr;
|
|
|
|
}
|
|
|
|
|
2021-11-11 01:44:58 +00:00
|
|
|
void StringAttrStorage::initialize(MLIRContext *context) {
|
|
|
|
// Check for a dialect namespace prefix, if there isn't one we don't need to
|
|
|
|
// do any additional initialization.
|
|
|
|
auto dialectNamePair = value.split('.');
|
|
|
|
if (dialectNamePair.first.empty() || dialectNamePair.second.empty())
|
|
|
|
return;
|
|
|
|
|
|
|
|
// If one exists, we check to see if this dialect is loaded. If it is, we set
|
|
|
|
// the dialect now, if it isn't we record this storage for initialization
|
|
|
|
// later if the dialect ever gets loaded.
|
|
|
|
if ((referencedDialect = context->getLoadedDialect(dialectNamePair.first)))
|
|
|
|
return;
|
|
|
|
|
|
|
|
MLIRContextImpl &impl = context->getImpl();
|
|
|
|
llvm::sys::SmartScopedLock<true> lock(impl.dialectRefStrAttrMutex);
|
|
|
|
impl.dialectReferencingStrAttrs[dialectNamePair.first].push_back(this);
|
|
|
|
}
|
|
|
|
|
2021-05-25 14:38:01 -07:00
|
|
|
/// Return an empty string.
|
|
|
|
StringAttr StringAttr::get(MLIRContext *context) {
|
|
|
|
return context->getImpl().emptyStringAttr;
|
|
|
|
}
|
|
|
|
|
2018-07-04 10:43:29 -07:00
|
|
|
//===----------------------------------------------------------------------===//
|
2019-05-21 01:34:13 -07:00
|
|
|
// AffineMap uniquing
|
2018-07-04 10:43:29 -07:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2019-05-21 01:34:13 -07:00
|
|
|
StorageUniquer &MLIRContext::getAffineUniquer() {
|
|
|
|
return getImpl().affineUniquer;
|
|
|
|
}
|
|
|
|
|
2019-08-07 10:31:14 -07:00
|
|
|
AffineMap AffineMap::getImpl(unsigned dimCount, unsigned symbolCount,
|
|
|
|
ArrayRef<AffineExpr> results,
|
|
|
|
MLIRContext *context) {
|
|
|
|
auto &impl = context->getImpl();
|
2021-12-02 23:49:02 +01:00
|
|
|
auto *storage = impl.affineUniquer.get<AffineMapStorage>(
|
|
|
|
[&](AffineMapStorage *storage) { storage->context = context; }, dimCount,
|
|
|
|
symbolCount, results);
|
|
|
|
return AffineMap(storage);
|
2018-06-29 18:09:29 -07:00
|
|
|
}
|
|
|
|
|
2021-11-27 00:36:09 +05:30
|
|
|
/// Check whether the arguments passed to the AffineMap::get() are consistent.
|
|
|
|
/// This method checks whether the highest index of dimensional identifier
|
|
|
|
/// present in result expressions is less than `dimCount` and the highest index
|
|
|
|
/// of symbolic identifier present in result expressions is less than
|
|
|
|
/// `symbolCount`.
|
2021-12-04 04:23:21 +00:00
|
|
|
LLVM_ATTRIBUTE_UNUSED static bool
|
|
|
|
willBeValidAffineMap(unsigned dimCount, unsigned symbolCount,
|
|
|
|
ArrayRef<AffineExpr> results) {
|
2021-11-27 00:36:09 +05:30
|
|
|
int64_t maxDimPosition = -1;
|
|
|
|
int64_t maxSymbolPosition = -1;
|
|
|
|
getMaxDimAndSymbol(ArrayRef<ArrayRef<AffineExpr>>(results), maxDimPosition,
|
|
|
|
maxSymbolPosition);
|
|
|
|
if ((maxDimPosition >= dimCount) || (maxSymbolPosition >= symbolCount)) {
|
|
|
|
LLVM_DEBUG(
|
|
|
|
llvm::dbgs()
|
|
|
|
<< "maximum dimensional identifier position in result expression must "
|
|
|
|
"be less than `dimCount` and maximum symbolic identifier position "
|
|
|
|
"in result expression must be less than `symbolCount`\n");
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2019-08-07 10:31:14 -07:00
|
|
|
AffineMap AffineMap::get(MLIRContext *context) {
|
|
|
|
return getImpl(/*dimCount=*/0, /*symbolCount=*/0, /*results=*/{}, context);
|
|
|
|
}
|
|
|
|
|
2020-03-10 15:10:34 -04:00
|
|
|
AffineMap AffineMap::get(unsigned dimCount, unsigned symbolCount,
|
|
|
|
MLIRContext *context) {
|
2020-04-01 10:47:06 +02:00
|
|
|
return getImpl(dimCount, symbolCount, /*results=*/{}, context);
|
2020-03-10 15:10:34 -04:00
|
|
|
}
|
|
|
|
|
2019-08-07 10:31:14 -07:00
|
|
|
AffineMap AffineMap::get(unsigned dimCount, unsigned symbolCount,
|
[MLIR] Improve support for 0-dimensional Affine Maps.
Summary:
Modified AffineMap::get to remove support for the overload which allowed
an ArrayRef of AffineExpr but no context (and gathered the context from a
presumed first entry, resulting in bugs when there were 0 results).
Instead, we support only a ArrayRef and a context, and a version which
takes a single AffineExpr.
Additionally, removed some now needless case logic which previously
special cased which call to AffineMap::get to use.
Reviewers: flaub, bondhugula, rriddle!, nicolasvasilache, ftynse, ulysseB, mravishankar, antiagainst, aartbik
Subscribers: mehdi_amini, jpienaar, burmako, shauheen, antiagainst, arpith-jacob, mgester, lucyrfox, liufengdb, Joonsoo, bader, grosul1, frgossen, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D78226
2020-04-15 11:12:47 -07:00
|
|
|
AffineExpr result) {
|
2021-11-27 00:36:09 +05:30
|
|
|
assert(willBeValidAffineMap(dimCount, symbolCount, {result}));
|
[MLIR] Improve support for 0-dimensional Affine Maps.
Summary:
Modified AffineMap::get to remove support for the overload which allowed
an ArrayRef of AffineExpr but no context (and gathered the context from a
presumed first entry, resulting in bugs when there were 0 results).
Instead, we support only a ArrayRef and a context, and a version which
takes a single AffineExpr.
Additionally, removed some now needless case logic which previously
special cased which call to AffineMap::get to use.
Reviewers: flaub, bondhugula, rriddle!, nicolasvasilache, ftynse, ulysseB, mravishankar, antiagainst, aartbik
Subscribers: mehdi_amini, jpienaar, burmako, shauheen, antiagainst, arpith-jacob, mgester, lucyrfox, liufengdb, Joonsoo, bader, grosul1, frgossen, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D78226
2020-04-15 11:12:47 -07:00
|
|
|
return getImpl(dimCount, symbolCount, {result}, result.getContext());
|
2019-08-07 10:31:14 -07:00
|
|
|
}
|
|
|
|
|
2020-04-01 10:47:06 +02:00
|
|
|
AffineMap AffineMap::get(unsigned dimCount, unsigned symbolCount,
|
|
|
|
ArrayRef<AffineExpr> results, MLIRContext *context) {
|
2021-11-27 00:36:09 +05:30
|
|
|
assert(willBeValidAffineMap(dimCount, symbolCount, results));
|
2020-04-01 10:47:06 +02:00
|
|
|
return getImpl(dimCount, symbolCount, results, context);
|
|
|
|
}
|
|
|
|
|
2018-08-07 14:24:38 -07:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// Integer Sets: these are allocated into the bump pointer, and are immutable.
|
2018-10-25 08:33:02 -07:00
|
|
|
// Unlike AffineMap's, these are uniqued only if they are small.
|
2018-08-07 14:24:38 -07:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2018-10-10 09:45:59 -07:00
|
|
|
IntegerSet IntegerSet::get(unsigned dimCount, unsigned symbolCount,
|
|
|
|
ArrayRef<AffineExpr> constraints,
|
2018-10-25 08:33:02 -07:00
|
|
|
ArrayRef<bool> eqFlags) {
|
|
|
|
// The number of constraints can't be zero.
|
|
|
|
assert(!constraints.empty());
|
|
|
|
assert(constraints.size() == eqFlags.size());
|
2018-08-07 14:24:38 -07:00
|
|
|
|
2018-10-25 08:33:02 -07:00
|
|
|
auto &impl = constraints[0].getContext()->getImpl();
|
2021-12-02 23:49:02 +01:00
|
|
|
auto *storage = impl.affineUniquer.get<IntegerSetStorage>(
|
|
|
|
[](IntegerSetStorage *) {}, dimCount, symbolCount, constraints, eqFlags);
|
|
|
|
return IntegerSet(storage);
|
2018-08-07 14:24:38 -07:00
|
|
|
}
|
2020-02-20 10:31:44 -08:00
|
|
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// StorageUniquerSupport
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2021-02-22 17:30:19 -08:00
|
|
|
/// Utility method to generate a callback that can be used to generate a
|
|
|
|
/// diagnostic when checking the construction invariants of a storage object.
|
|
|
|
/// This is defined out-of-line to avoid the need to include Location.h.
|
|
|
|
llvm::unique_function<InFlightDiagnostic()>
|
|
|
|
mlir::detail::getDefaultDiagnosticEmitFn(MLIRContext *ctx) {
|
|
|
|
return [ctx] { return emitError(UnknownLoc::get(ctx)); };
|
|
|
|
}
|
|
|
|
llvm::unique_function<InFlightDiagnostic()>
|
|
|
|
mlir::detail::getDefaultDiagnosticEmitFn(const Location &loc) {
|
|
|
|
return [=] { return emitError(loc); };
|
2020-02-20 10:31:44 -08:00
|
|
|
}
|