2018-07-06 10:46:19 -07:00
|
|
|
//===- Verifier.cpp - MLIR Verifier Implementation ------------------------===//
|
|
|
|
//
|
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-07-06 10:46:19 -07:00
|
|
|
//
|
2019-12-23 09:35:36 -08:00
|
|
|
//===----------------------------------------------------------------------===//
|
2018-07-06 10:46:19 -07:00
|
|
|
//
|
|
|
|
// This file implements the verify() methods on the various IR types, performing
|
|
|
|
// (potentially expensive) checks on the holistic structure of the code. This
|
|
|
|
// can be used for detecting bugs in compiler transformations and hand written
|
|
|
|
// .mlir files.
|
|
|
|
//
|
|
|
|
// The checks in this file are only for things that can occur as part of IR
|
|
|
|
// transformations: e.g. violation of dominance information, malformed operation
|
|
|
|
// attributes, etc. MLIR supports transformations moving IR through locally
|
2019-03-27 08:55:17 -07:00
|
|
|
// invalid states (e.g. unlinking an operation from a block before re-inserting
|
|
|
|
// it in a new place), but each transformation must complete with the IR in a
|
|
|
|
// valid form.
|
2018-07-06 10:46:19 -07:00
|
|
|
//
|
|
|
|
// This should not check for things that are always wrong by construction (e.g.
|
2019-06-07 09:46:13 -07:00
|
|
|
// attributes or other immutable structures that are incorrect), because those
|
2018-07-06 10:46:19 -07:00
|
|
|
// are not mutable and can be checked at time of construction.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2020-04-30 13:09:13 -07:00
|
|
|
#include "mlir/IR/Verifier.h"
|
2018-08-21 08:42:19 -07:00
|
|
|
#include "mlir/IR/Attributes.h"
|
2019-03-02 22:34:18 -08:00
|
|
|
#include "mlir/IR/Dialect.h"
|
2020-04-30 13:09:13 -07:00
|
|
|
#include "mlir/IR/Dominance.h"
|
2019-03-26 14:45:38 -07:00
|
|
|
#include "mlir/IR/Operation.h"
|
[MLIR] Add RegionKindInterface
Some dialects have semantics which is not well represented by common
SSA structures with dominance constraints. This patch allows
operations to declare the 'kind' of their contained regions.
Currently, two kinds are allowed: "SSACFG" and "Graph". The only
difference between them at the moment is that SSACFG regions are
required to have dominance, while Graph regions are not required to
have dominance. The intention is that this Interface would be
generated by ODS for existing operations, although this has not yet
been implemented. Presumably, if someone were interested in code
generation, we might also have a "CFG" dialect, which defines control
flow, but does not require SSA.
The new behavior is mostly identical to the previous behavior, since
registered operations without a RegionKindInterface are assumed to
contain SSACFG regions. However, the behavior has changed for
unregistered operations. Previously, these were checked for
dominance, however the new behavior allows dominance violations, in
order to allow the processing of unregistered dialects with Graph
regions. One implication of this is that regions in unregistered
operations with more than one op are no longer CSE'd (since it
requires dominance info).
I've also reorganized the LangRef documentation to remove assertions
about "sequential execution", "SSA Values", and "Dominance". Instead,
the core IR is simply "ordered" (i.e. totally ordered) and consists of
"Values". I've also clarified some things about how control flow
passes between blocks in an SSACFG region. Control Flow must enter a
region at the entry block and follow terminator operation successors
or be returned to the containing op. Graph regions do not define a
notion of control flow.
see discussion here:
https://llvm.discourse.group/t/rfc-allowing-dialects-to-relax-the-ssa-dominance-condition/833/53
Differential Revision: https://reviews.llvm.org/D80358
2020-05-15 10:33:13 -07:00
|
|
|
#include "mlir/IR/RegionKindInterface.h"
|
2019-10-19 13:38:31 -07:00
|
|
|
#include "llvm/ADT/StringMap.h"
|
2019-02-28 09:30:52 -08:00
|
|
|
#include "llvm/Support/FormatVariadic.h"
|
2018-08-05 21:12:29 -07:00
|
|
|
#include "llvm/Support/PrettyStackTrace.h"
|
2019-02-26 16:43:12 -08:00
|
|
|
#include "llvm/Support/Regex.h"
|
2019-10-19 13:38:31 -07:00
|
|
|
|
2018-07-06 10:46:19 -07:00
|
|
|
using namespace mlir;
|
|
|
|
|
2018-07-21 14:32:09 -07:00
|
|
|
namespace {
|
2019-06-07 09:46:13 -07:00
|
|
|
/// This class encapsulates all the state used to verify an operation region.
|
|
|
|
class OperationVerifier {
|
2018-07-21 14:32:09 -07:00
|
|
|
public:
|
2020-03-11 13:22:19 -07:00
|
|
|
explicit OperationVerifier(MLIRContext *ctx) : ctx(ctx) {}
|
2019-04-02 10:24:11 -07:00
|
|
|
|
2019-06-10 18:37:09 -07:00
|
|
|
/// Verify the given operation.
|
|
|
|
LogicalResult verify(Operation &op);
|
|
|
|
|
2019-03-02 22:34:18 -08:00
|
|
|
/// Returns the registered dialect for a dialect-specific attribute.
|
2019-03-31 23:30:22 -07:00
|
|
|
Dialect *getDialectForAttribute(const NamedAttribute &attr) {
|
2019-03-02 22:34:18 -08:00
|
|
|
assert(attr.first.strref().contains('.') && "expected dialect attribute");
|
|
|
|
auto dialectNamePair = attr.first.strref().split('.');
|
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 ctx->getLoadedDialect(dialectNamePair.first);
|
2019-03-02 22:34:18 -08:00
|
|
|
}
|
|
|
|
|
2019-06-07 09:46:13 -07:00
|
|
|
private:
|
|
|
|
/// Verify the given potentially nested region or block.
|
2019-06-10 18:37:09 -07:00
|
|
|
LogicalResult verifyRegion(Region ®ion);
|
|
|
|
LogicalResult verifyBlock(Block &block);
|
2019-04-02 10:24:11 -07:00
|
|
|
LogicalResult verifyOperation(Operation &op);
|
2019-06-07 09:46:13 -07:00
|
|
|
|
[MLIR] Add RegionKindInterface
Some dialects have semantics which is not well represented by common
SSA structures with dominance constraints. This patch allows
operations to declare the 'kind' of their contained regions.
Currently, two kinds are allowed: "SSACFG" and "Graph". The only
difference between them at the moment is that SSACFG regions are
required to have dominance, while Graph regions are not required to
have dominance. The intention is that this Interface would be
generated by ODS for existing operations, although this has not yet
been implemented. Presumably, if someone were interested in code
generation, we might also have a "CFG" dialect, which defines control
flow, but does not require SSA.
The new behavior is mostly identical to the previous behavior, since
registered operations without a RegionKindInterface are assumed to
contain SSACFG regions. However, the behavior has changed for
unregistered operations. Previously, these were checked for
dominance, however the new behavior allows dominance violations, in
order to allow the processing of unregistered dialects with Graph
regions. One implication of this is that regions in unregistered
operations with more than one op are no longer CSE'd (since it
requires dominance info).
I've also reorganized the LangRef documentation to remove assertions
about "sequential execution", "SSA Values", and "Dominance". Instead,
the core IR is simply "ordered" (i.e. totally ordered) and consists of
"Values". I've also clarified some things about how control flow
passes between blocks in an SSACFG region. Control Flow must enter a
region at the entry block and follow terminator operation successors
or be returned to the containing op. Graph regions do not define a
notion of control flow.
see discussion here:
https://llvm.discourse.group/t/rfc-allowing-dialects-to-relax-the-ssa-dominance-condition/833/53
Differential Revision: https://reviews.llvm.org/D80358
2020-05-15 10:33:13 -07:00
|
|
|
/// Verify the dominance property of operations within the given Region.
|
2019-06-07 09:46:13 -07:00
|
|
|
LogicalResult verifyDominance(Region ®ion);
|
[MLIR] Add RegionKindInterface
Some dialects have semantics which is not well represented by common
SSA structures with dominance constraints. This patch allows
operations to declare the 'kind' of their contained regions.
Currently, two kinds are allowed: "SSACFG" and "Graph". The only
difference between them at the moment is that SSACFG regions are
required to have dominance, while Graph regions are not required to
have dominance. The intention is that this Interface would be
generated by ODS for existing operations, although this has not yet
been implemented. Presumably, if someone were interested in code
generation, we might also have a "CFG" dialect, which defines control
flow, but does not require SSA.
The new behavior is mostly identical to the previous behavior, since
registered operations without a RegionKindInterface are assumed to
contain SSACFG regions. However, the behavior has changed for
unregistered operations. Previously, these were checked for
dominance, however the new behavior allows dominance violations, in
order to allow the processing of unregistered dialects with Graph
regions. One implication of this is that regions in unregistered
operations with more than one op are no longer CSE'd (since it
requires dominance info).
I've also reorganized the LangRef documentation to remove assertions
about "sequential execution", "SSA Values", and "Dominance". Instead,
the core IR is simply "ordered" (i.e. totally ordered) and consists of
"Values". I've also clarified some things about how control flow
passes between blocks in an SSACFG region. Control Flow must enter a
region at the entry block and follow terminator operation successors
or be returned to the containing op. Graph regions do not define a
notion of control flow.
see discussion here:
https://llvm.discourse.group/t/rfc-allowing-dialects-to-relax-the-ssa-dominance-condition/833/53
Differential Revision: https://reviews.llvm.org/D80358
2020-05-15 10:33:13 -07:00
|
|
|
|
|
|
|
/// Verify the dominance property of regions contained within the given
|
|
|
|
/// Operation.
|
|
|
|
LogicalResult verifyDominanceOfContainedRegions(Operation &op);
|
2018-12-29 09:11:58 -08:00
|
|
|
|
2019-06-07 09:46:13 -07:00
|
|
|
/// Emit an error for the given block.
|
|
|
|
InFlightDiagnostic emitError(Block &bb, const Twine &message) {
|
|
|
|
// Take the location information for the first operation in the block.
|
|
|
|
if (!bb.empty())
|
|
|
|
return bb.front().emitError(message);
|
2018-07-21 14:32:09 -07:00
|
|
|
|
2019-06-07 09:46:13 -07:00
|
|
|
// Worst case, fall back to using the parent's location.
|
2019-06-25 21:31:54 -07:00
|
|
|
return mlir::emitError(bb.getParent()->getLoc(), message);
|
2019-06-07 09:46:13 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
/// The current context for the verifier.
|
|
|
|
MLIRContext *ctx;
|
2018-12-29 09:11:58 -08:00
|
|
|
|
2019-07-03 13:21:24 -07:00
|
|
|
/// Dominance information for this operation, when checking dominance.
|
2018-12-29 09:11:58 -08:00
|
|
|
DominanceInfo *domInfo = nullptr;
|
2019-02-26 16:43:12 -08:00
|
|
|
|
2019-03-31 23:30:22 -07:00
|
|
|
/// Mapping between dialect namespace and if that dialect supports
|
|
|
|
/// unregistered operations.
|
|
|
|
llvm::StringMap<bool> dialectAllowsUnknownOps;
|
2018-07-21 14:32:09 -07:00
|
|
|
};
|
|
|
|
} // end anonymous namespace
|
2018-07-06 10:46:19 -07:00
|
|
|
|
2019-06-10 18:37:09 -07:00
|
|
|
/// Verify the given operation.
|
|
|
|
LogicalResult OperationVerifier::verify(Operation &op) {
|
|
|
|
// Verify the operation first.
|
|
|
|
if (failed(verifyOperation(op)))
|
|
|
|
return failure();
|
|
|
|
|
|
|
|
// Since everything looks structurally ok to this point, we do a dominance
|
|
|
|
// check for any nested regions. We do this as a second pass since malformed
|
|
|
|
// CFG's can cause dominator analysis constructure to crash and we want the
|
|
|
|
// verifier to be resilient to malformed code.
|
|
|
|
DominanceInfo theDomInfo(&op);
|
|
|
|
domInfo = &theDomInfo;
|
[MLIR] Add RegionKindInterface
Some dialects have semantics which is not well represented by common
SSA structures with dominance constraints. This patch allows
operations to declare the 'kind' of their contained regions.
Currently, two kinds are allowed: "SSACFG" and "Graph". The only
difference between them at the moment is that SSACFG regions are
required to have dominance, while Graph regions are not required to
have dominance. The intention is that this Interface would be
generated by ODS for existing operations, although this has not yet
been implemented. Presumably, if someone were interested in code
generation, we might also have a "CFG" dialect, which defines control
flow, but does not require SSA.
The new behavior is mostly identical to the previous behavior, since
registered operations without a RegionKindInterface are assumed to
contain SSACFG regions. However, the behavior has changed for
unregistered operations. Previously, these were checked for
dominance, however the new behavior allows dominance violations, in
order to allow the processing of unregistered dialects with Graph
regions. One implication of this is that regions in unregistered
operations with more than one op are no longer CSE'd (since it
requires dominance info).
I've also reorganized the LangRef documentation to remove assertions
about "sequential execution", "SSA Values", and "Dominance". Instead,
the core IR is simply "ordered" (i.e. totally ordered) and consists of
"Values". I've also clarified some things about how control flow
passes between blocks in an SSACFG region. Control Flow must enter a
region at the entry block and follow terminator operation successors
or be returned to the containing op. Graph regions do not define a
notion of control flow.
see discussion here:
https://llvm.discourse.group/t/rfc-allowing-dialects-to-relax-the-ssa-dominance-condition/833/53
Differential Revision: https://reviews.llvm.org/D80358
2020-05-15 10:33:13 -07:00
|
|
|
if (failed(verifyDominanceOfContainedRegions(op)))
|
|
|
|
return failure();
|
2018-12-29 09:11:58 -08:00
|
|
|
|
|
|
|
domInfo = nullptr;
|
2019-04-02 10:24:11 -07:00
|
|
|
return success();
|
2018-12-29 09:11:58 -08:00
|
|
|
}
|
|
|
|
|
2019-06-10 18:37:09 -07:00
|
|
|
LogicalResult OperationVerifier::verifyRegion(Region ®ion) {
|
2019-06-07 09:46:13 -07:00
|
|
|
if (region.empty())
|
|
|
|
return success();
|
|
|
|
|
|
|
|
// Verify the first block has no predecessors.
|
|
|
|
auto *firstBB = ®ion.front();
|
|
|
|
if (!firstBB->hasNoPredecessors())
|
2019-06-25 21:31:54 -07:00
|
|
|
return mlir::emitError(region.getLoc(),
|
|
|
|
"entry block of region may not have predecessors");
|
2019-06-07 09:46:13 -07:00
|
|
|
|
|
|
|
// Verify each of the blocks within the region.
|
[MLIR] Add RegionKindInterface
Some dialects have semantics which is not well represented by common
SSA structures with dominance constraints. This patch allows
operations to declare the 'kind' of their contained regions.
Currently, two kinds are allowed: "SSACFG" and "Graph". The only
difference between them at the moment is that SSACFG regions are
required to have dominance, while Graph regions are not required to
have dominance. The intention is that this Interface would be
generated by ODS for existing operations, although this has not yet
been implemented. Presumably, if someone were interested in code
generation, we might also have a "CFG" dialect, which defines control
flow, but does not require SSA.
The new behavior is mostly identical to the previous behavior, since
registered operations without a RegionKindInterface are assumed to
contain SSACFG regions. However, the behavior has changed for
unregistered operations. Previously, these were checked for
dominance, however the new behavior allows dominance violations, in
order to allow the processing of unregistered dialects with Graph
regions. One implication of this is that regions in unregistered
operations with more than one op are no longer CSE'd (since it
requires dominance info).
I've also reorganized the LangRef documentation to remove assertions
about "sequential execution", "SSA Values", and "Dominance". Instead,
the core IR is simply "ordered" (i.e. totally ordered) and consists of
"Values". I've also clarified some things about how control flow
passes between blocks in an SSACFG region. Control Flow must enter a
region at the entry block and follow terminator operation successors
or be returned to the containing op. Graph regions do not define a
notion of control flow.
see discussion here:
https://llvm.discourse.group/t/rfc-allowing-dialects-to-relax-the-ssa-dominance-condition/833/53
Differential Revision: https://reviews.llvm.org/D80358
2020-05-15 10:33:13 -07:00
|
|
|
for (Block &block : region)
|
2019-06-10 18:37:09 -07:00
|
|
|
if (failed(verifyBlock(block)))
|
2019-06-07 09:46:13 -07:00
|
|
|
return failure();
|
|
|
|
return success();
|
|
|
|
}
|
|
|
|
|
2019-06-10 18:37:09 -07:00
|
|
|
LogicalResult OperationVerifier::verifyBlock(Block &block) {
|
2019-12-22 21:59:55 -08:00
|
|
|
for (auto arg : block.getArguments())
|
2020-01-11 08:54:04 -08:00
|
|
|
if (arg.getOwner() != &block)
|
2019-06-07 09:46:13 -07:00
|
|
|
return emitError(block, "block argument not owned by block");
|
2018-12-29 09:11:58 -08:00
|
|
|
|
2019-02-08 09:52:26 -08:00
|
|
|
// Verify that this block has a terminator.
|
2019-06-07 09:46:13 -07:00
|
|
|
if (block.empty())
|
|
|
|
return emitError(block, "block with no terminator");
|
2019-02-08 09:52:26 -08:00
|
|
|
|
2019-03-27 08:55:17 -07:00
|
|
|
// Verify the non-terminator operations separately so that we can verify
|
2019-02-08 09:52:26 -08:00
|
|
|
// they has no successors.
|
2019-03-27 08:55:17 -07:00
|
|
|
for (auto &op : llvm::make_range(block.begin(), std::prev(block.end()))) {
|
|
|
|
if (op.getNumSuccessors() != 0)
|
2019-06-07 09:46:13 -07:00
|
|
|
return op.emitError(
|
|
|
|
"operation with block successors must terminate its parent block");
|
2019-02-08 09:52:26 -08:00
|
|
|
|
2019-04-02 10:24:11 -07:00
|
|
|
if (failed(verifyOperation(op)))
|
|
|
|
return failure();
|
2019-01-25 12:48:25 -08:00
|
|
|
}
|
|
|
|
|
2019-02-08 09:52:26 -08:00
|
|
|
// Verify the terminator.
|
2021-02-09 11:41:10 -08:00
|
|
|
Operation &terminator = block.back();
|
|
|
|
if (failed(verifyOperation(terminator)))
|
2019-04-02 10:24:11 -07:00
|
|
|
return failure();
|
2021-02-09 11:41:10 -08:00
|
|
|
if (!terminator.mightHaveTrait<OpTrait::IsTerminator>())
|
2020-11-06 16:24:35 -08:00
|
|
|
return block.back().emitError("block with no terminator");
|
2019-02-08 09:52:26 -08:00
|
|
|
|
|
|
|
// Verify that this block is not branching to a block of a different
|
|
|
|
// region.
|
2019-03-21 17:53:00 -07:00
|
|
|
for (Block *successor : block.getSuccessors())
|
2019-02-08 09:52:26 -08:00
|
|
|
if (successor->getParent() != block.getParent())
|
2019-06-07 09:46:13 -07:00
|
|
|
return block.back().emitOpError(
|
|
|
|
"branching to block of a different region");
|
2019-02-08 09:52:26 -08:00
|
|
|
|
2019-04-02 10:24:11 -07:00
|
|
|
return success();
|
2018-12-29 09:11:58 -08:00
|
|
|
}
|
|
|
|
|
2019-06-07 09:46:13 -07:00
|
|
|
LogicalResult OperationVerifier::verifyOperation(Operation &op) {
|
2018-09-05 17:45:19 -07:00
|
|
|
// Check that operands are non-nil and structurally ok.
|
2019-12-22 21:59:55 -08:00
|
|
|
for (auto operand : op.getOperands())
|
2018-09-05 17:45:19 -07:00
|
|
|
if (!operand)
|
2019-06-07 09:46:13 -07:00
|
|
|
return op.emitError("null operand found");
|
2018-08-21 08:42:19 -07:00
|
|
|
|
2019-02-26 16:43:12 -08:00
|
|
|
/// Verify that all of the attributes are okay.
|
2018-08-21 08:42:19 -07:00
|
|
|
for (auto attr : op.getAttrs()) {
|
2019-03-02 22:34:18 -08:00
|
|
|
// Check for any optional dialect specific attributes.
|
|
|
|
if (!attr.first.strref().contains('.'))
|
|
|
|
continue;
|
2019-03-31 23:30:22 -07:00
|
|
|
if (auto *dialect = getDialectForAttribute(attr))
|
2019-04-02 14:02:32 -07:00
|
|
|
if (failed(dialect->verifyOperationAttribute(&op, attr)))
|
2019-04-02 10:24:11 -07:00
|
|
|
return failure();
|
2018-08-21 08:42:19 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
// If we can get operation info for this, check the custom hook.
|
2019-03-31 23:30:22 -07:00
|
|
|
auto *opInfo = op.getAbstractOperation();
|
2019-04-02 13:09:34 -07:00
|
|
|
if (opInfo && failed(opInfo->verifyInvariants(&op)))
|
2019-04-02 10:24:11 -07:00
|
|
|
return failure();
|
2018-08-21 08:42:19 -07:00
|
|
|
|
[MLIR] Add RegionKindInterface
Some dialects have semantics which is not well represented by common
SSA structures with dominance constraints. This patch allows
operations to declare the 'kind' of their contained regions.
Currently, two kinds are allowed: "SSACFG" and "Graph". The only
difference between them at the moment is that SSACFG regions are
required to have dominance, while Graph regions are not required to
have dominance. The intention is that this Interface would be
generated by ODS for existing operations, although this has not yet
been implemented. Presumably, if someone were interested in code
generation, we might also have a "CFG" dialect, which defines control
flow, but does not require SSA.
The new behavior is mostly identical to the previous behavior, since
registered operations without a RegionKindInterface are assumed to
contain SSACFG regions. However, the behavior has changed for
unregistered operations. Previously, these were checked for
dominance, however the new behavior allows dominance violations, in
order to allow the processing of unregistered dialects with Graph
regions. One implication of this is that regions in unregistered
operations with more than one op are no longer CSE'd (since it
requires dominance info).
I've also reorganized the LangRef documentation to remove assertions
about "sequential execution", "SSA Values", and "Dominance". Instead,
the core IR is simply "ordered" (i.e. totally ordered) and consists of
"Values". I've also clarified some things about how control flow
passes between blocks in an SSACFG region. Control Flow must enter a
region at the entry block and follow terminator operation successors
or be returned to the containing op. Graph regions do not define a
notion of control flow.
see discussion here:
https://llvm.discourse.group/t/rfc-allowing-dialects-to-relax-the-ssa-dominance-condition/833/53
Differential Revision: https://reviews.llvm.org/D80358
2020-05-15 10:33:13 -07:00
|
|
|
auto kindInterface = dyn_cast<mlir::RegionKindInterface>(op);
|
|
|
|
|
2019-06-07 09:46:13 -07:00
|
|
|
// Verify that all child regions are ok.
|
[MLIR] Add RegionKindInterface
Some dialects have semantics which is not well represented by common
SSA structures with dominance constraints. This patch allows
operations to declare the 'kind' of their contained regions.
Currently, two kinds are allowed: "SSACFG" and "Graph". The only
difference between them at the moment is that SSACFG regions are
required to have dominance, while Graph regions are not required to
have dominance. The intention is that this Interface would be
generated by ODS for existing operations, although this has not yet
been implemented. Presumably, if someone were interested in code
generation, we might also have a "CFG" dialect, which defines control
flow, but does not require SSA.
The new behavior is mostly identical to the previous behavior, since
registered operations without a RegionKindInterface are assumed to
contain SSACFG regions. However, the behavior has changed for
unregistered operations. Previously, these were checked for
dominance, however the new behavior allows dominance violations, in
order to allow the processing of unregistered dialects with Graph
regions. One implication of this is that regions in unregistered
operations with more than one op are no longer CSE'd (since it
requires dominance info).
I've also reorganized the LangRef documentation to remove assertions
about "sequential execution", "SSA Values", and "Dominance". Instead,
the core IR is simply "ordered" (i.e. totally ordered) and consists of
"Values". I've also clarified some things about how control flow
passes between blocks in an SSACFG region. Control Flow must enter a
region at the entry block and follow terminator operation successors
or be returned to the containing op. Graph regions do not define a
notion of control flow.
see discussion here:
https://llvm.discourse.group/t/rfc-allowing-dialects-to-relax-the-ssa-dominance-condition/833/53
Differential Revision: https://reviews.llvm.org/D80358
2020-05-15 10:33:13 -07:00
|
|
|
unsigned numRegions = op.getNumRegions();
|
|
|
|
for (unsigned i = 0; i < numRegions; i++) {
|
|
|
|
Region ®ion = op.getRegion(i);
|
|
|
|
// Check that Graph Regions only have a single basic block. This is
|
|
|
|
// similar to the code in SingleBlockImplicitTerminator, but doesn't
|
|
|
|
// require the trait to be specified. This arbitrary limitation is
|
|
|
|
// designed to limit the number of cases that have to be handled by
|
|
|
|
// transforms and conversions until the concept stabilizes.
|
|
|
|
if (op.isRegistered() && kindInterface &&
|
|
|
|
kindInterface.getRegionKind(i) == RegionKind::Graph) {
|
|
|
|
// Empty regions are fine.
|
|
|
|
if (region.empty())
|
|
|
|
continue;
|
|
|
|
|
|
|
|
// Non-empty regions must contain a single basic block.
|
|
|
|
if (std::next(region.begin()) != region.end())
|
|
|
|
return op.emitOpError("expects graph region #")
|
|
|
|
<< i << " to have 0 or 1 blocks";
|
|
|
|
}
|
2019-06-10 18:37:09 -07:00
|
|
|
if (failed(verifyRegion(region)))
|
2019-06-07 09:46:13 -07:00
|
|
|
return failure();
|
[MLIR] Add RegionKindInterface
Some dialects have semantics which is not well represented by common
SSA structures with dominance constraints. This patch allows
operations to declare the 'kind' of their contained regions.
Currently, two kinds are allowed: "SSACFG" and "Graph". The only
difference between them at the moment is that SSACFG regions are
required to have dominance, while Graph regions are not required to
have dominance. The intention is that this Interface would be
generated by ODS for existing operations, although this has not yet
been implemented. Presumably, if someone were interested in code
generation, we might also have a "CFG" dialect, which defines control
flow, but does not require SSA.
The new behavior is mostly identical to the previous behavior, since
registered operations without a RegionKindInterface are assumed to
contain SSACFG regions. However, the behavior has changed for
unregistered operations. Previously, these were checked for
dominance, however the new behavior allows dominance violations, in
order to allow the processing of unregistered dialects with Graph
regions. One implication of this is that regions in unregistered
operations with more than one op are no longer CSE'd (since it
requires dominance info).
I've also reorganized the LangRef documentation to remove assertions
about "sequential execution", "SSA Values", and "Dominance". Instead,
the core IR is simply "ordered" (i.e. totally ordered) and consists of
"Values". I've also clarified some things about how control flow
passes between blocks in an SSACFG region. Control Flow must enter a
region at the entry block and follow terminator operation successors
or be returned to the containing op. Graph regions do not define a
notion of control flow.
see discussion here:
https://llvm.discourse.group/t/rfc-allowing-dialects-to-relax-the-ssa-dominance-condition/833/53
Differential Revision: https://reviews.llvm.org/D80358
2020-05-15 10:33:13 -07:00
|
|
|
}
|
2019-01-25 12:48:25 -08:00
|
|
|
|
2019-03-31 23:30:22 -07:00
|
|
|
// If this is a registered operation, there is nothing left to do.
|
|
|
|
if (opInfo)
|
2019-04-02 10:24:11 -07:00
|
|
|
return success();
|
2019-03-31 23:30:22 -07:00
|
|
|
|
|
|
|
// Otherwise, verify that the parent dialect allows un-registered operations.
|
2019-06-03 16:32:25 -07:00
|
|
|
auto dialectPrefix = op.getName().getDialect();
|
2019-03-31 23:30:22 -07:00
|
|
|
|
|
|
|
// Check for an existing answer for the operation dialect.
|
|
|
|
auto it = dialectAllowsUnknownOps.find(dialectPrefix);
|
|
|
|
if (it == dialectAllowsUnknownOps.end()) {
|
|
|
|
// If the operation dialect is registered, query it directly.
|
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 (auto *dialect = ctx->getLoadedDialect(dialectPrefix))
|
2019-03-31 23:30:22 -07:00
|
|
|
it = dialectAllowsUnknownOps
|
|
|
|
.try_emplace(dialectPrefix, dialect->allowsUnknownOperations())
|
|
|
|
.first;
|
2020-03-29 22:35:38 +00:00
|
|
|
// Otherwise, unregistered dialects (when allowed by the context)
|
|
|
|
// conservatively allow unknown operations.
|
|
|
|
else {
|
|
|
|
if (!op.getContext()->allowsUnregisteredDialects() && !op.getDialect())
|
|
|
|
return op.emitOpError()
|
|
|
|
<< "created with unregistered dialect. If this is "
|
|
|
|
"intended, please call allowUnregisteredDialects() on the "
|
|
|
|
"MLIRContext, or use -allow-unregistered-dialect with "
|
|
|
|
"mlir-opt";
|
|
|
|
|
2019-03-31 23:30:22 -07:00
|
|
|
it = dialectAllowsUnknownOps.try_emplace(dialectPrefix, true).first;
|
2020-03-29 22:35:38 +00:00
|
|
|
}
|
2019-03-31 23:30:22 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
if (!it->second) {
|
2019-06-07 09:46:13 -07:00
|
|
|
return op.emitError("unregistered operation '")
|
|
|
|
<< op.getName() << "' found in dialect ('" << dialectPrefix
|
|
|
|
<< "') that does not allow unknown operations";
|
2019-03-31 23:30:22 -07:00
|
|
|
}
|
|
|
|
|
2019-04-02 10:24:11 -07:00
|
|
|
return success();
|
2018-08-21 08:42:19 -07:00
|
|
|
}
|
|
|
|
|
2020-12-16 04:18:41 +00:00
|
|
|
/// Attach a note to an in-flight diagnostic that provide more information about
|
|
|
|
/// where an op operand is defined.
|
|
|
|
static void attachNoteForOperandDefinition(InFlightDiagnostic &diag,
|
|
|
|
Operation &op, Value operand) {
|
|
|
|
if (auto *useOp = operand.getDefiningOp()) {
|
|
|
|
Diagnostic ¬e = diag.attachNote(useOp->getLoc());
|
|
|
|
note << "operand defined here";
|
|
|
|
Block *block1 = op.getBlock();
|
|
|
|
Block *block2 = useOp->getBlock();
|
|
|
|
Region *region1 = block1->getParent();
|
|
|
|
Region *region2 = block2->getParent();
|
|
|
|
if (block1 == block2)
|
|
|
|
note << " (op in the same block)";
|
|
|
|
else if (region1 == region2)
|
|
|
|
note << " (op in the same region)";
|
|
|
|
else if (region2->isProperAncestor(region1))
|
|
|
|
note << " (op in a parent region)";
|
|
|
|
else if (region1->isProperAncestor(region2))
|
|
|
|
note << " (op in a child region)";
|
|
|
|
else
|
|
|
|
note << " (op is neither in a parent nor in a child region)";
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
// Block argument case.
|
|
|
|
Block *block1 = op.getBlock();
|
|
|
|
Block *block2 = operand.cast<BlockArgument>().getOwner();
|
|
|
|
Region *region1 = block1->getParent();
|
|
|
|
Region *region2 = block2->getParent();
|
|
|
|
Location loc = UnknownLoc::get(op.getContext());
|
|
|
|
if (block2->getParentOp())
|
|
|
|
loc = block2->getParentOp()->getLoc();
|
|
|
|
Diagnostic ¬e = diag.attachNote(loc);
|
|
|
|
if (!region2) {
|
|
|
|
note << " (block without parent)";
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
if (block1 == block2)
|
|
|
|
llvm::report_fatal_error("Internal error in dominance verification");
|
|
|
|
int index = std::distance(region2->begin(), block2->getIterator());
|
|
|
|
note << "operand defined as a block argument (block #" << index;
|
|
|
|
if (region1 == region2)
|
|
|
|
note << " in the same region)";
|
|
|
|
else if (region2->isProperAncestor(region1))
|
|
|
|
note << " in a parent region)";
|
|
|
|
else if (region1->isProperAncestor(region2))
|
|
|
|
note << " in a child region)";
|
|
|
|
else
|
|
|
|
note << " neither in a parent nor in a child region)";
|
|
|
|
}
|
|
|
|
|
2019-06-10 18:37:09 -07:00
|
|
|
LogicalResult OperationVerifier::verifyDominance(Region ®ion) {
|
2019-03-27 08:55:17 -07:00
|
|
|
// Verify the dominance of each of the held operations.
|
[MLIR] Add RegionKindInterface
Some dialects have semantics which is not well represented by common
SSA structures with dominance constraints. This patch allows
operations to declare the 'kind' of their contained regions.
Currently, two kinds are allowed: "SSACFG" and "Graph". The only
difference between them at the moment is that SSACFG regions are
required to have dominance, while Graph regions are not required to
have dominance. The intention is that this Interface would be
generated by ODS for existing operations, although this has not yet
been implemented. Presumably, if someone were interested in code
generation, we might also have a "CFG" dialect, which defines control
flow, but does not require SSA.
The new behavior is mostly identical to the previous behavior, since
registered operations without a RegionKindInterface are assumed to
contain SSACFG regions. However, the behavior has changed for
unregistered operations. Previously, these were checked for
dominance, however the new behavior allows dominance violations, in
order to allow the processing of unregistered dialects with Graph
regions. One implication of this is that regions in unregistered
operations with more than one op are no longer CSE'd (since it
requires dominance info).
I've also reorganized the LangRef documentation to remove assertions
about "sequential execution", "SSA Values", and "Dominance". Instead,
the core IR is simply "ordered" (i.e. totally ordered) and consists of
"Values". I've also clarified some things about how control flow
passes between blocks in an SSACFG region. Control Flow must enter a
region at the entry block and follow terminator operation successors
or be returned to the containing op. Graph regions do not define a
notion of control flow.
see discussion here:
https://llvm.discourse.group/t/rfc-allowing-dialects-to-relax-the-ssa-dominance-condition/833/53
Differential Revision: https://reviews.llvm.org/D80358
2020-05-15 10:33:13 -07:00
|
|
|
for (Block &block : region) {
|
|
|
|
// Dominance is only meaningful inside reachable blocks.
|
2020-05-13 22:32:21 -07:00
|
|
|
if (domInfo->isReachableFromEntry(&block))
|
[MLIR] Add RegionKindInterface
Some dialects have semantics which is not well represented by common
SSA structures with dominance constraints. This patch allows
operations to declare the 'kind' of their contained regions.
Currently, two kinds are allowed: "SSACFG" and "Graph". The only
difference between them at the moment is that SSACFG regions are
required to have dominance, while Graph regions are not required to
have dominance. The intention is that this Interface would be
generated by ODS for existing operations, although this has not yet
been implemented. Presumably, if someone were interested in code
generation, we might also have a "CFG" dialect, which defines control
flow, but does not require SSA.
The new behavior is mostly identical to the previous behavior, since
registered operations without a RegionKindInterface are assumed to
contain SSACFG regions. However, the behavior has changed for
unregistered operations. Previously, these were checked for
dominance, however the new behavior allows dominance violations, in
order to allow the processing of unregistered dialects with Graph
regions. One implication of this is that regions in unregistered
operations with more than one op are no longer CSE'd (since it
requires dominance info).
I've also reorganized the LangRef documentation to remove assertions
about "sequential execution", "SSA Values", and "Dominance". Instead,
the core IR is simply "ordered" (i.e. totally ordered) and consists of
"Values". I've also clarified some things about how control flow
passes between blocks in an SSACFG region. Control Flow must enter a
region at the entry block and follow terminator operation successors
or be returned to the containing op. Graph regions do not define a
notion of control flow.
see discussion here:
https://llvm.discourse.group/t/rfc-allowing-dialects-to-relax-the-ssa-dominance-condition/833/53
Differential Revision: https://reviews.llvm.org/D80358
2020-05-15 10:33:13 -07:00
|
|
|
for (Operation &op : block)
|
|
|
|
// Check that operands properly dominate this use.
|
|
|
|
for (unsigned operandNo = 0, e = op.getNumOperands(); operandNo != e;
|
|
|
|
++operandNo) {
|
2020-12-16 04:18:41 +00:00
|
|
|
Value operand = op.getOperand(operandNo);
|
[MLIR] Add RegionKindInterface
Some dialects have semantics which is not well represented by common
SSA structures with dominance constraints. This patch allows
operations to declare the 'kind' of their contained regions.
Currently, two kinds are allowed: "SSACFG" and "Graph". The only
difference between them at the moment is that SSACFG regions are
required to have dominance, while Graph regions are not required to
have dominance. The intention is that this Interface would be
generated by ODS for existing operations, although this has not yet
been implemented. Presumably, if someone were interested in code
generation, we might also have a "CFG" dialect, which defines control
flow, but does not require SSA.
The new behavior is mostly identical to the previous behavior, since
registered operations without a RegionKindInterface are assumed to
contain SSACFG regions. However, the behavior has changed for
unregistered operations. Previously, these were checked for
dominance, however the new behavior allows dominance violations, in
order to allow the processing of unregistered dialects with Graph
regions. One implication of this is that regions in unregistered
operations with more than one op are no longer CSE'd (since it
requires dominance info).
I've also reorganized the LangRef documentation to remove assertions
about "sequential execution", "SSA Values", and "Dominance". Instead,
the core IR is simply "ordered" (i.e. totally ordered) and consists of
"Values". I've also clarified some things about how control flow
passes between blocks in an SSACFG region. Control Flow must enter a
region at the entry block and follow terminator operation successors
or be returned to the containing op. Graph regions do not define a
notion of control flow.
see discussion here:
https://llvm.discourse.group/t/rfc-allowing-dialects-to-relax-the-ssa-dominance-condition/833/53
Differential Revision: https://reviews.llvm.org/D80358
2020-05-15 10:33:13 -07:00
|
|
|
if (domInfo->properlyDominates(operand, &op))
|
|
|
|
continue;
|
|
|
|
|
2020-12-16 04:18:41 +00:00
|
|
|
InFlightDiagnostic diag = op.emitError("operand #")
|
|
|
|
<< operandNo
|
|
|
|
<< " does not dominate this use";
|
|
|
|
attachNoteForOperandDefinition(diag, op, operand);
|
2020-05-13 22:32:21 -07:00
|
|
|
return failure();
|
[MLIR] Add RegionKindInterface
Some dialects have semantics which is not well represented by common
SSA structures with dominance constraints. This patch allows
operations to declare the 'kind' of their contained regions.
Currently, two kinds are allowed: "SSACFG" and "Graph". The only
difference between them at the moment is that SSACFG regions are
required to have dominance, while Graph regions are not required to
have dominance. The intention is that this Interface would be
generated by ODS for existing operations, although this has not yet
been implemented. Presumably, if someone were interested in code
generation, we might also have a "CFG" dialect, which defines control
flow, but does not require SSA.
The new behavior is mostly identical to the previous behavior, since
registered operations without a RegionKindInterface are assumed to
contain SSACFG regions. However, the behavior has changed for
unregistered operations. Previously, these were checked for
dominance, however the new behavior allows dominance violations, in
order to allow the processing of unregistered dialects with Graph
regions. One implication of this is that regions in unregistered
operations with more than one op are no longer CSE'd (since it
requires dominance info).
I've also reorganized the LangRef documentation to remove assertions
about "sequential execution", "SSA Values", and "Dominance". Instead,
the core IR is simply "ordered" (i.e. totally ordered) and consists of
"Values". I've also clarified some things about how control flow
passes between blocks in an SSACFG region. Control Flow must enter a
region at the entry block and follow terminator operation successors
or be returned to the containing op. Graph regions do not define a
notion of control flow.
see discussion here:
https://llvm.discourse.group/t/rfc-allowing-dialects-to-relax-the-ssa-dominance-condition/833/53
Differential Revision: https://reviews.llvm.org/D80358
2020-05-15 10:33:13 -07:00
|
|
|
}
|
|
|
|
// Recursively verify dominance within each operation in the
|
|
|
|
// block, even if the block itself is not reachable, or we are in
|
|
|
|
// a region which doesn't respect dominance.
|
|
|
|
for (Operation &op : block)
|
|
|
|
if (failed(verifyDominanceOfContainedRegions(op)))
|
|
|
|
return failure();
|
|
|
|
}
|
2019-04-02 10:24:11 -07:00
|
|
|
return success();
|
2018-07-06 10:46:19 -07:00
|
|
|
}
|
|
|
|
|
[MLIR] Add RegionKindInterface
Some dialects have semantics which is not well represented by common
SSA structures with dominance constraints. This patch allows
operations to declare the 'kind' of their contained regions.
Currently, two kinds are allowed: "SSACFG" and "Graph". The only
difference between them at the moment is that SSACFG regions are
required to have dominance, while Graph regions are not required to
have dominance. The intention is that this Interface would be
generated by ODS for existing operations, although this has not yet
been implemented. Presumably, if someone were interested in code
generation, we might also have a "CFG" dialect, which defines control
flow, but does not require SSA.
The new behavior is mostly identical to the previous behavior, since
registered operations without a RegionKindInterface are assumed to
contain SSACFG regions. However, the behavior has changed for
unregistered operations. Previously, these were checked for
dominance, however the new behavior allows dominance violations, in
order to allow the processing of unregistered dialects with Graph
regions. One implication of this is that regions in unregistered
operations with more than one op are no longer CSE'd (since it
requires dominance info).
I've also reorganized the LangRef documentation to remove assertions
about "sequential execution", "SSA Values", and "Dominance". Instead,
the core IR is simply "ordered" (i.e. totally ordered) and consists of
"Values". I've also clarified some things about how control flow
passes between blocks in an SSACFG region. Control Flow must enter a
region at the entry block and follow terminator operation successors
or be returned to the containing op. Graph regions do not define a
notion of control flow.
see discussion here:
https://llvm.discourse.group/t/rfc-allowing-dialects-to-relax-the-ssa-dominance-condition/833/53
Differential Revision: https://reviews.llvm.org/D80358
2020-05-15 10:33:13 -07:00
|
|
|
/// Verify the dominance of each of the nested blocks within the given operation
|
|
|
|
LogicalResult
|
|
|
|
OperationVerifier::verifyDominanceOfContainedRegions(Operation &op) {
|
|
|
|
for (Region ®ion : op.getRegions()) {
|
2019-06-10 18:37:09 -07:00
|
|
|
if (failed(verifyDominance(region)))
|
|
|
|
return failure();
|
[MLIR] Add RegionKindInterface
Some dialects have semantics which is not well represented by common
SSA structures with dominance constraints. This patch allows
operations to declare the 'kind' of their contained regions.
Currently, two kinds are allowed: "SSACFG" and "Graph". The only
difference between them at the moment is that SSACFG regions are
required to have dominance, while Graph regions are not required to
have dominance. The intention is that this Interface would be
generated by ODS for existing operations, although this has not yet
been implemented. Presumably, if someone were interested in code
generation, we might also have a "CFG" dialect, which defines control
flow, but does not require SSA.
The new behavior is mostly identical to the previous behavior, since
registered operations without a RegionKindInterface are assumed to
contain SSACFG regions. However, the behavior has changed for
unregistered operations. Previously, these were checked for
dominance, however the new behavior allows dominance violations, in
order to allow the processing of unregistered dialects with Graph
regions. One implication of this is that regions in unregistered
operations with more than one op are no longer CSE'd (since it
requires dominance info).
I've also reorganized the LangRef documentation to remove assertions
about "sequential execution", "SSA Values", and "Dominance". Instead,
the core IR is simply "ordered" (i.e. totally ordered) and consists of
"Values". I've also clarified some things about how control flow
passes between blocks in an SSACFG region. Control Flow must enter a
region at the entry block and follow terminator operation successors
or be returned to the containing op. Graph regions do not define a
notion of control flow.
see discussion here:
https://llvm.discourse.group/t/rfc-allowing-dialects-to-relax-the-ssa-dominance-condition/833/53
Differential Revision: https://reviews.llvm.org/D80358
2020-05-15 10:33:13 -07:00
|
|
|
}
|
2019-04-02 10:24:11 -07:00
|
|
|
return success();
|
2018-09-21 14:40:36 -07:00
|
|
|
}
|
|
|
|
|
2018-07-06 10:46:19 -07:00
|
|
|
//===----------------------------------------------------------------------===//
|
2019-07-03 13:21:24 -07:00
|
|
|
// Entrypoint
|
2018-07-06 10:46:19 -07:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
/// Perform (potentially expensive) checks of invariants, used to detect
|
2018-09-07 09:08:13 -07:00
|
|
|
/// compiler bugs. On error, this reports the error through the MLIRContext and
|
2019-04-02 10:24:11 -07:00
|
|
|
/// returns failure.
|
2019-07-02 15:00:38 -07:00
|
|
|
LogicalResult mlir::verify(Operation *op) {
|
|
|
|
return OperationVerifier(op->getContext()).verify(*op);
|
|
|
|
}
|