2020-06-12 08:47:14 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
//
|
|
|
|
|
// This file is licensed under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
|
|
|
|
//
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
|
|
#include "npcomp/InitAll.h"
|
|
|
|
|
|
2021-02-23 04:08:17 +08:00
|
|
|
#include "mlir/IR/Dialect.h"
|
Add npcomp-verify-backend-contract pass.
This pass verifies that a given module satisfies the contract that we
have for backends. This is phrased as an "allowlist", because we want to
keep this interface tight. Also, this gives much better diagnostics than
a backend randomly crashing or failing to compile would (though they
could still be improved).
This was especially painful because if we had
`tensor<?x!numpy.any_dtype>` slip through, at some point RefBackend
would convert it to a memref type and trip the "verify type invariants"
assertion which gives no location or anything and crashed the process,
which was very unpleasant.
We implement this with the dialect conversion framework, which works
reasonably well and was quick to put together and familiar, but is still
very "op oriented". We probably want to make this hand-rolled
eventually, especially the error reporting (the most useful kind of
error for a dialect conversion user is not necessarily the best for this
use case). Also, in production, these error will go to users, and need
to be surfaced carefully such as "the compiler needs a type annotation
on this function parameter" which in general requires some special
analysis, wordsmithing, and overall awareness of the e2e use case (such
as how much we can lean into certain source locations) to provide a
meaningful user-level diagnostic.
Also, add `inline` to the current frontend lowering pass pipeline to
allow slightly more complicated programs that otherwise would fail on
shape inference.
2021-04-13 09:39:53 +08:00
|
|
|
#include "npcomp/Backend/Common/Passes.h"
|
2021-04-09 04:05:16 +08:00
|
|
|
#include "npcomp/Backend/IREE/Passes.h"
|
2021-02-23 04:08:17 +08:00
|
|
|
#include "npcomp/Conversion/Passes.h"
|
2020-06-12 08:47:14 +08:00
|
|
|
#include "npcomp/Dialect/Basicpy/IR/BasicpyDialect.h"
|
|
|
|
|
#include "npcomp/Dialect/Basicpy/Transforms/Passes.h"
|
|
|
|
|
#include "npcomp/Dialect/Numpy/IR/NumpyDialect.h"
|
2020-07-09 13:51:54 +08:00
|
|
|
#include "npcomp/Dialect/Numpy/Transforms/Passes.h"
|
2020-10-08 08:30:10 +08:00
|
|
|
#include "npcomp/Dialect/Refback/IR/RefbackDialect.h"
|
|
|
|
|
#include "npcomp/Dialect/Refbackrt/IR/RefbackrtDialect.h"
|
2020-06-12 08:47:14 +08:00
|
|
|
#include "npcomp/Dialect/TCF/IR/TCFDialect.h"
|
2020-07-11 12:51:03 +08:00
|
|
|
#include "npcomp/Dialect/TCF/Transforms/Passes.h"
|
2020-06-12 08:47:14 +08:00
|
|
|
#include "npcomp/Dialect/TCP/IR/TCPDialect.h"
|
2020-10-16 03:26:21 +08:00
|
|
|
#include "npcomp/Dialect/TCP/Transforms/Passes.h"
|
2020-09-29 03:02:35 +08:00
|
|
|
#include "npcomp/Dialect/Torch/IR/TorchDialect.h"
|
2021-02-18 03:28:51 +08:00
|
|
|
#include "npcomp/Dialect/Torch/Transforms/Passes.h"
|
2020-10-07 07:14:37 +08:00
|
|
|
#include "npcomp/RefBackend/RefBackend.h"
|
2021-02-23 04:08:17 +08:00
|
|
|
#include "npcomp/Typing/Transforms/Passes.h"
|
2020-06-12 08:47:14 +08:00
|
|
|
|
2020-08-28 06:09:10 +08:00
|
|
|
void mlir::NPCOMP::registerAllDialects(mlir::DialectRegistry ®istry) {
|
|
|
|
|
// clang-format off
|
Significantly restructure torch/aten import design.
This is a really major and invasive restructuring of the way we get
torch operators (`torch::jit::Operator` / `c10::OperatorHandle`) into
MLIR. Please forgive the challenging review, but due to the sheer
invasiveness, it wasn't really practical do do it in sane smaller
pieces.
This fully replaces everything that was already working on the
TorchScript path (actually, more -- we added tanh support to
TorchToLinalg in order to delete the older code paths). Additionally,
I've kept the lights on for the acap path too, including what little e2e
stuff was working before (for expediency I made a few tiny compromises
along the way that will be easy to undo when we give that path proper
attention).
Overview of the new design:
- The torch operator `somens::someunqualname.someoverloadname` is
imported as `torch.somens.someunqualname.someoverloadname` (skip the
last dotted part if the overload name is empty), OR, if we don't have
such an op registered, it is imported as
`torch.operator "somens.someunqualname.someoverloadname" (...) : ...`.
- The addition of the "overload name" is a critical element here, as
the `(ns,unqual,overload)` triple is unique, which solves a lot of
problems we were having.
- This involves having separate MLIR ops for the `trailing_` and
`.out` variants and all the different overloads. This seemed
necessary, because the set of overloads is so wild and varied and
unstructured. The previous design was leaning into some underlying
structure that just isn't there -- the default situation is
the "random overload that we want to manage on the MLIR side",
rather than that being an exception. E.g. `aten::ne` (not-equal)
has 21 overloads, only 4 of which are c10 dispatcher ops see
[gist](https://gist.github.com/silvasean/190ba918c550c956260e21254e1b8aa1),
and the "out" variant is really called `.Tensor_out` instead of
`.out` as it frequently is for other ops.
- Rationale for all being in `torch` namespace: the set of operators
are so varied and unstructured that "dialect per namespace"
doesn't result in anything resembling the typical MLIR dialect
boundary expectations. We could maybe draw the boundary at
dispatcher ops vs non-dispatcher ops, but that doesn't seem to
really result in very much useful structure at this point in time.
- Note: within the torch operator registry, we effectively have a
mini-basicpy subdialect (already type-resolved), which is reasonably
structured.
- The existing Torch op interfaces are also removed -- now that we
track the overload name, we can losslessly find the original
operator.
- Instead of `ATenRecognizeKernelsPass`, we now have a
`ReduceOpVariantsPass` that keys off certain traits (and perhaps
eventually interfaces) to reduce variants of ops to a smaller set,
ideally operating on immutable tensors and using surrounding ops to
model the mutability/aliasing aspects.
- Note: `torch.ns.unqual.overload` ops allow both immutable and
mutable tensors (unlike the previous hard distinction in the common
case). This is a premonition for a future change that will introduce a
bona fide `!torch.tensor` type that will clean up a bunch of stuff.
- `TorchToLinalg` / `TorchToStd` supercede the existing
"ATen->TCF->TCP->Linalg" path.
- The new `torch_ods_gen.py` supercedes `torch_signature_ods_gen.py`.
It should look somewhat familiar, but the benefit of hindsight has
allowed a lot of simplifications.
The overall trend seems to be to make the `torch` dialect a nice layer
independent of anything else. It feels like as a natural result of
various future changes we will be removing the reliance on basicpy+numpy
dialects and have a nice self-contained type system too that properly
models the TorchScript type system (including proper subtyping,
mutable/immutable tensors, optional dtype, etc.).
Recommended review order:
- Start at some of the new import IR, e.g. in
`frontends/pytorch/test/node_import/prim.py`,
`frontends/pytorch/test/acap_export/test_export_add3.py`, and other
tests.
- `frontends/pytorch/python/torch_mlir_utils/codegen/torch_ods_gen.py`
and associated generated files:
- `include/npcomp/Dialect/Torch/IR/GeneratedAtenOps.td`
- `include/npcomp/Dialect/Torch/IR/GeneratedPrimOps.td`
- Inspect `ReduceOpVariants.cpp` / `reduce-op-variants.mlir` and the new
traits in `include/npcomp/Dialect/Torch/IR/TorchTraits.h`
- Various code changes in the import path in
`frontends/pytorch/csrc/builder`. Probably most interesting is the new
code in `torch_to_mlir_utils.cpp` that has the logic to create the
`torch.operator` ops or `torch.ns.unqual.overload` ops.
This is the [new ResNet IR](https://gist.github.com/silvasean/5407aafb710d07612b7b5b92eabecebe),
just to be able to look at a substantial sample of IR in the new style.
2021-05-05 05:42:50 +08:00
|
|
|
registry.insert<Basicpy::BasicpyDialect,
|
2020-08-28 06:09:10 +08:00
|
|
|
Numpy::NumpyDialect,
|
2020-10-08 08:12:52 +08:00
|
|
|
refbackrt::RefbackrtDialect,
|
2020-10-08 08:30:10 +08:00
|
|
|
refback::RefbackDialect,
|
2020-08-28 06:09:10 +08:00
|
|
|
tcf::TCFDialect,
|
2020-09-29 03:02:35 +08:00
|
|
|
tcp::TCPDialect,
|
|
|
|
|
mlir::NPCOMP::Torch::TorchDialect>();
|
2020-08-28 06:09:10 +08:00
|
|
|
// clang-format on
|
2020-06-12 08:47:14 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void mlir::NPCOMP::registerAllPasses() {
|
2020-10-07 07:14:37 +08:00
|
|
|
mlir::NPCOMP::registerRefBackendPasses();
|
2020-08-28 06:09:10 +08:00
|
|
|
mlir::NPCOMP::registerConversionPasses();
|
|
|
|
|
mlir::NPCOMP::registerBasicpyPasses();
|
|
|
|
|
mlir::NPCOMP::registerNumpyPasses();
|
|
|
|
|
mlir::NPCOMP::registerTCFPasses();
|
2020-10-16 03:26:21 +08:00
|
|
|
mlir::NPCOMP::registerTCPPasses();
|
2021-02-18 03:28:51 +08:00
|
|
|
mlir::NPCOMP::registerTorchPasses();
|
2020-08-28 06:09:10 +08:00
|
|
|
mlir::NPCOMP::registerTypingPasses();
|
2021-04-09 04:05:16 +08:00
|
|
|
mlir::NPCOMP::IREEBackend::registerIREEBackendPasses();
|
Add npcomp-verify-backend-contract pass.
This pass verifies that a given module satisfies the contract that we
have for backends. This is phrased as an "allowlist", because we want to
keep this interface tight. Also, this gives much better diagnostics than
a backend randomly crashing or failing to compile would (though they
could still be improved).
This was especially painful because if we had
`tensor<?x!numpy.any_dtype>` slip through, at some point RefBackend
would convert it to a memref type and trip the "verify type invariants"
assertion which gives no location or anything and crashed the process,
which was very unpleasant.
We implement this with the dialect conversion framework, which works
reasonably well and was quick to put together and familiar, but is still
very "op oriented". We probably want to make this hand-rolled
eventually, especially the error reporting (the most useful kind of
error for a dialect conversion user is not necessarily the best for this
use case). Also, in production, these error will go to users, and need
to be surfaced carefully such as "the compiler needs a type annotation
on this function parameter" which in general requires some special
analysis, wordsmithing, and overall awareness of the e2e use case (such
as how much we can lean into certain source locations) to provide a
meaningful user-level diagnostic.
Also, add `inline` to the current frontend lowering pass pipeline to
allow slightly more complicated programs that otherwise would fail on
shape inference.
2021-04-13 09:39:53 +08:00
|
|
|
mlir::NPCOMP::CommonBackend::registerCommonBackendPasses();
|
2020-06-12 08:47:14 +08:00
|
|
|
}
|
