2021-02-02 09:59:42 +08:00
|
|
|
//===- node_importer.cpp --------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// This file is licensed under a pytorch-style license
|
|
|
|
// See frontends/pytorch/LICENSE for license information.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#include "node_importer.h"
|
|
|
|
|
|
|
|
#include <unordered_map>
|
|
|
|
|
|
|
|
#include "mlir_utils.h"
|
|
|
|
#include "op_builder.h"
|
|
|
|
|
|
|
|
#include "mlir-c/BuiltinAttributes.h"
|
|
|
|
#include "mlir-c/BuiltinTypes.h"
|
|
|
|
#include "mlir-c/Diagnostics.h"
|
2021-02-19 09:10:17 +08:00
|
|
|
#include "npcomp-c/Types.h"
|
2021-02-02 09:59:42 +08:00
|
|
|
|
|
|
|
namespace py = pybind11;
|
|
|
|
using namespace torch_mlir;
|
|
|
|
|
|
|
|
using Value = torch::jit::Value;
|
|
|
|
using Block = torch::jit::Block;
|
|
|
|
using Node = torch::jit::Node;
|
|
|
|
|
|
|
|
namespace {
|
|
|
|
class NodeImporter {
|
|
|
|
public:
|
|
|
|
NodeImporter(MlirContext context) : context(context) {}
|
|
|
|
|
|
|
|
void importNode(Node *node, MlirBlock appendToBlock);
|
2021-03-02 09:24:15 +08:00
|
|
|
MlirBlock importBlock(Block *jitBlock, CreateTerminatorFn createTerminator);
|
2021-02-02 09:59:42 +08:00
|
|
|
|
|
|
|
private:
|
|
|
|
MlirBlock createBlockFor(Block *jitBlock);
|
|
|
|
void mapValue(Value *jitValue, MlirValue value);
|
|
|
|
void mapResults(Node *node, MlirOperation operation);
|
|
|
|
MlirValue lookupMappedValue(Value *jitValue);
|
|
|
|
std::vector<MlirValue> lookupMappedValues(c10::ArrayRef<Value *> values);
|
|
|
|
|
|
|
|
MlirContext context;
|
|
|
|
std::unordered_map<Value *, MlirValue> valueMap;
|
|
|
|
};
|
|
|
|
} // namespace
|
|
|
|
|
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
|
|
|
void NodeImporter::importNode(Node *node, MlirBlock appendToBlock) {
|
2021-02-02 09:59:42 +08:00
|
|
|
TypeMapper typeMapper(context);
|
|
|
|
MlirLocation loc = getMlirLocationFromNode(context, node);
|
|
|
|
auto kind = node->kind();
|
2021-03-11 08:55:29 +08:00
|
|
|
|
|
|
|
auto createAndMapTrivialNode = [&](Node *node, const std::string &opName) {
|
|
|
|
MlirOperation operation =
|
|
|
|
createMlirOperationAtEnd(appendToBlock, opName, loc,
|
|
|
|
getMlirTypesFromValues(loc, node->outputs()),
|
|
|
|
lookupMappedValues(node->inputs()));
|
|
|
|
mapResults(node, operation);
|
|
|
|
};
|
|
|
|
auto createAndMapNodeWithAttribute = [&](Node *node,
|
|
|
|
const std::string &opName,
|
|
|
|
const std::string &attrName,
|
|
|
|
MlirAttribute attr) {
|
|
|
|
MlirOperation operation =
|
|
|
|
createMlirOperationAtEnd(appendToBlock, opName, loc,
|
|
|
|
getMlirTypesFromValues(loc, node->outputs()),
|
|
|
|
lookupMappedValues(node->inputs()),
|
|
|
|
toMlirNamedAttribute(attrName.c_str(), attr));
|
|
|
|
mapResults(node, operation);
|
|
|
|
};
|
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
|
|
|
|
|
|
|
// Trivial ops with schema.
|
|
|
|
auto maybeSchema = node->maybeSchema();
|
|
|
|
if (maybeSchema) {
|
|
|
|
MlirOperation operation =
|
|
|
|
createOperationFromSchema(appendToBlock, loc, node->schema(),
|
|
|
|
getMlirTypesFromValues(loc, node->outputs()),
|
|
|
|
lookupMappedValues(node->inputs()));
|
|
|
|
mapResults(node, operation);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Builtin interpreter ops with no operator/schema.
|
2021-03-11 08:55:29 +08:00
|
|
|
switch (kind) {
|
|
|
|
case c10::prim::ListUnpack:
|
|
|
|
createAndMapTrivialNode(node,
|
|
|
|
"torch.prim." + std::string(kind.toUnqualString()));
|
|
|
|
return;
|
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
|
|
|
case c10::prim::GetAttr:
|
|
|
|
case c10::prim::SetAttr: {
|
|
|
|
createAndMapNodeWithAttribute(
|
|
|
|
node, "torch.prim." + std::string(kind.toUnqualString()), "name",
|
|
|
|
importAttribute(loc, node, c10::attr::name));
|
|
|
|
return;
|
2021-03-11 08:55:29 +08:00
|
|
|
}
|
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
|
|
|
}
|
|
|
|
|
|
|
|
// Ops trivially lowered through `basicpy` dialect.
|
|
|
|
switch (kind) {
|
2021-03-11 08:55:29 +08:00
|
|
|
case c10::prim::ListConstruct: {
|
|
|
|
createAndMapTrivialNode(node, "basicpy.build_list");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
case c10::prim::TupleConstruct: {
|
|
|
|
createAndMapTrivialNode(node, "basicpy.build_tuple");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-02-02 09:59:42 +08:00
|
|
|
if (kind == c10::prim::Constant) {
|
|
|
|
auto output = node->output();
|
|
|
|
MlirOperation op;
|
|
|
|
OpBuilder builder(context);
|
|
|
|
if (output->type()->cast<c10::NoneType>()) {
|
|
|
|
op = builder.createNoneConstant(loc);
|
|
|
|
} else if (output->type()->cast<c10::BoolType>()) {
|
|
|
|
op = builder.createBoolConstant(
|
|
|
|
loc, static_cast<bool>(node->i(c10::attr::value)));
|
2021-02-06 06:54:04 +08:00
|
|
|
} else if (output->type()->cast<c10::StringType>()) {
|
|
|
|
// TODO: Are TorchScript strings bytes or str technically?
|
|
|
|
// For now, model it as bytes to avoid pledging more than we currently
|
|
|
|
// model (e.g. no unicode, etc.).
|
|
|
|
op = builder.createBytesConstant(loc, node->s(c10::attr::value));
|
Properly import the entire torch::jit::CompilationUnit
This primarily unlocks proper handling of free functions (that is,
functions that are not methods of any torch.nn.Module).
Recommended review order:
- `ivalue_importer.cpp` + `ivalue_import/functions*.py`
- `GlobalizeObjectGraph.cpp` + test case
- misc other stuff
The `torch::jit::CompilationUnit` is basically a backing store or
"context" holding all the possible functions in the program. The
previous code was not explicitly accessing this data structure, since it
just imported the `torch::jit::Function`'s that it saw attached to
methods.
Subtly, any time a TorchScript module called into a free function, the
free function gets incorporated into the torch::jit::CompilationUnit,
but doesn't show up anywhere when dumping the module, except in the
curious pattern:
```
%5 : Function = prim::Constant[name="adaptive_avg_pool2d"]()
%6 : Tensor = prim::CallFunction(%5, %input.1, %4)
```
That is, calls are indirect calls, and are accessed via `prim::Constant`
materializing a function object. Even stranger, the `name` attribute here
doesn't really even tell the full story -- it doesn't correspond to
anything. It turns out that the c10::FunctionType itself actually holds
a pointer to the `torch::jit::Function` in the compilation unit
directly (so there is actually no indirection in prim::CallMethod,
because any two values of the same FunctionType call the same
function!). E.g. when converting the IR to bytecode, the "name" is
ignored [code link](https://github.com/pytorch/pytorch/blob/1d6bd157902d4b1347a5d03122d02b407658e263/torch/csrc/jit/runtime/interpreter.cpp#L937).
We do import `prim::CallFunction` as a `std.call_indirect` though
because it's more braindead to do it that way (it gets canonicalized to
a direct call easily).
2021-02-27 08:20:35 +08:00
|
|
|
} else if (auto functionType = output->type()->cast<c10::FunctionType>()) {
|
|
|
|
torch::jit::Function *function = functionType->function();
|
|
|
|
const std::string &symName = function->qualname().qualifiedName();
|
|
|
|
op = createMlirOperation(
|
|
|
|
"std.constant", loc,
|
2021-03-02 09:24:15 +08:00
|
|
|
getFunctionTypeFromSchema(context, function->getSchema()),
|
Properly import the entire torch::jit::CompilationUnit
This primarily unlocks proper handling of free functions (that is,
functions that are not methods of any torch.nn.Module).
Recommended review order:
- `ivalue_importer.cpp` + `ivalue_import/functions*.py`
- `GlobalizeObjectGraph.cpp` + test case
- misc other stuff
The `torch::jit::CompilationUnit` is basically a backing store or
"context" holding all the possible functions in the program. The
previous code was not explicitly accessing this data structure, since it
just imported the `torch::jit::Function`'s that it saw attached to
methods.
Subtly, any time a TorchScript module called into a free function, the
free function gets incorporated into the torch::jit::CompilationUnit,
but doesn't show up anywhere when dumping the module, except in the
curious pattern:
```
%5 : Function = prim::Constant[name="adaptive_avg_pool2d"]()
%6 : Tensor = prim::CallFunction(%5, %input.1, %4)
```
That is, calls are indirect calls, and are accessed via `prim::Constant`
materializing a function object. Even stranger, the `name` attribute here
doesn't really even tell the full story -- it doesn't correspond to
anything. It turns out that the c10::FunctionType itself actually holds
a pointer to the `torch::jit::Function` in the compilation unit
directly (so there is actually no indirection in prim::CallMethod,
because any two values of the same FunctionType call the same
function!). E.g. when converting the IR to bytecode, the "name" is
ignored [code link](https://github.com/pytorch/pytorch/blob/1d6bd157902d4b1347a5d03122d02b407658e263/torch/csrc/jit/runtime/interpreter.cpp#L937).
We do import `prim::CallFunction` as a `std.call_indirect` though
because it's more braindead to do it that way (it gets canonicalized to
a direct call easily).
2021-02-27 08:20:35 +08:00
|
|
|
toMlirNamedAttribute(
|
|
|
|
"value",
|
|
|
|
mlirFlatSymbolRefAttrGet(context, toMlirStringRef(symName))));
|
2021-02-02 09:59:42 +08:00
|
|
|
} else {
|
|
|
|
MlirAttribute valueAttr = importAttribute(loc, node, c10::attr::value);
|
|
|
|
op = builder.createStdConstant(loc, valueAttr);
|
|
|
|
}
|
|
|
|
mlirBlockAppendOwnedOperation(appendToBlock, op);
|
|
|
|
mapResults(node, op);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2021-03-02 07:00:32 +08:00
|
|
|
if (kind == c10::prim::Loop) {
|
2021-03-02 09:24:15 +08:00
|
|
|
std::vector<MlirType> resultTypes =
|
|
|
|
getMlirTypesFromValues(loc, node->outputs());
|
2021-03-02 07:00:32 +08:00
|
|
|
MlirOperation operation = createMlirOperationAtEnd(
|
2021-03-02 09:24:15 +08:00
|
|
|
appendToBlock, "torch.prim.Loop", loc, resultTypes,
|
|
|
|
lookupMappedValues(node->inputs().slice(0, 2)),
|
|
|
|
derefineValues(lookupMappedValues(node->inputs().slice(2)), resultTypes,
|
|
|
|
loc, appendToBlock),
|
|
|
|
mlirRegionCreate());
|
2021-03-02 07:00:32 +08:00
|
|
|
mapResults(node, operation);
|
2021-03-02 09:24:15 +08:00
|
|
|
std::vector<MlirType> terminatorOperandTypes = {npcompBoolTypeGet(context)};
|
|
|
|
terminatorOperandTypes.insert(terminatorOperandTypes.end(),
|
|
|
|
resultTypes.begin(), resultTypes.end());
|
|
|
|
auto createTerminator = [&](c10::ArrayRef<MlirValue> yieldedValues,
|
|
|
|
MlirBlock appendToBlock) {
|
|
|
|
createMlirOperationAtEnd(appendToBlock, "torch.prim.Loop.condition", loc,
|
|
|
|
derefineValues(yieldedValues,
|
|
|
|
terminatorOperandTypes, loc,
|
|
|
|
appendToBlock));
|
|
|
|
};
|
2021-03-02 07:00:32 +08:00
|
|
|
mlirRegionAppendOwnedBlock(
|
|
|
|
mlirOperationGetRegion(operation, 0),
|
2021-03-02 09:24:15 +08:00
|
|
|
importBlock(node->blocks()[0], createTerminator));
|
2021-03-02 07:00:32 +08:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2021-02-02 09:59:42 +08:00
|
|
|
if (kind == c10::prim::If) {
|
|
|
|
// TorchScript will already have an explicit op to determine truthiness. So
|
|
|
|
// all we need to do here is launder !basicpy.BoolType to i1 for `scf.if`.
|
|
|
|
MlirOperation pred = createMlirOperationAtEnd(
|
|
|
|
appendToBlock, "basicpy.bool_cast", loc, mlirIntegerTypeGet(context, 1),
|
|
|
|
lookupMappedValue(node->input()));
|
2021-03-02 09:24:15 +08:00
|
|
|
std::vector<MlirType> resultTypes =
|
|
|
|
getMlirTypesFromValues(loc, node->outputs());
|
2021-02-02 09:59:42 +08:00
|
|
|
MlirOperation operation = createMlirOperationAtEnd(
|
|
|
|
appendToBlock, "scf.if", loc, mlirOperationGetResult(pred, 0),
|
2021-03-02 09:24:15 +08:00
|
|
|
resultTypes, mlirRegionCreate(), mlirRegionCreate());
|
2021-02-02 09:59:42 +08:00
|
|
|
mapResults(node, operation);
|
2021-03-02 09:24:15 +08:00
|
|
|
auto createTerminator =
|
|
|
|
[&](c10::ArrayRef<MlirValue> yieldedValues, MlirBlock appendToBlock) {
|
|
|
|
createMlirOperationAtEnd(
|
|
|
|
appendToBlock, "scf.yield", loc,
|
|
|
|
derefineValues(yieldedValues, resultTypes, loc, appendToBlock));
|
|
|
|
};
|
|
|
|
mlirRegionAppendOwnedBlock(
|
|
|
|
mlirOperationGetRegion(operation, 0),
|
|
|
|
importBlock(node->blocks()[0], createTerminator));
|
|
|
|
mlirRegionAppendOwnedBlock(
|
|
|
|
mlirOperationGetRegion(operation, 1),
|
|
|
|
importBlock(node->blocks()[1], createTerminator));
|
2021-02-02 09:59:42 +08:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2021-03-11 09:25:39 +08:00
|
|
|
if (kind == c10::prim::CallMethod) {
|
|
|
|
auto classType = node->input(0)->type()->cast<c10::ClassType>();
|
|
|
|
auto methodName = node->s(c10::attr::name);
|
|
|
|
torch::jit::Function *function = classType->findMethod(methodName);
|
|
|
|
torch::jit::Block *calleeEntryBlock = function->graph()->block();
|
|
|
|
auto expectedTypes = c10::fmap(calleeEntryBlock->inputs(), [&](Value *v) {
|
|
|
|
return typeMapper.mapFromTorchType(loc, v->type());
|
|
|
|
});
|
|
|
|
MlirOperation operation = createMlirOperationAtEnd(
|
|
|
|
appendToBlock, "torch.prim.CallMethod", loc,
|
|
|
|
getMlirTypesFromValues(loc, node->outputs()),
|
|
|
|
derefineValues(lookupMappedValues(node->inputs()), expectedTypes, loc,
|
|
|
|
appendToBlock),
|
|
|
|
toMlirNamedAttribute("name",
|
|
|
|
importAttribute(loc, node, c10::attr::name)));
|
|
|
|
mapResults(node, operation);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
Properly import the entire torch::jit::CompilationUnit
This primarily unlocks proper handling of free functions (that is,
functions that are not methods of any torch.nn.Module).
Recommended review order:
- `ivalue_importer.cpp` + `ivalue_import/functions*.py`
- `GlobalizeObjectGraph.cpp` + test case
- misc other stuff
The `torch::jit::CompilationUnit` is basically a backing store or
"context" holding all the possible functions in the program. The
previous code was not explicitly accessing this data structure, since it
just imported the `torch::jit::Function`'s that it saw attached to
methods.
Subtly, any time a TorchScript module called into a free function, the
free function gets incorporated into the torch::jit::CompilationUnit,
but doesn't show up anywhere when dumping the module, except in the
curious pattern:
```
%5 : Function = prim::Constant[name="adaptive_avg_pool2d"]()
%6 : Tensor = prim::CallFunction(%5, %input.1, %4)
```
That is, calls are indirect calls, and are accessed via `prim::Constant`
materializing a function object. Even stranger, the `name` attribute here
doesn't really even tell the full story -- it doesn't correspond to
anything. It turns out that the c10::FunctionType itself actually holds
a pointer to the `torch::jit::Function` in the compilation unit
directly (so there is actually no indirection in prim::CallMethod,
because any two values of the same FunctionType call the same
function!). E.g. when converting the IR to bytecode, the "name" is
ignored [code link](https://github.com/pytorch/pytorch/blob/1d6bd157902d4b1347a5d03122d02b407658e263/torch/csrc/jit/runtime/interpreter.cpp#L937).
We do import `prim::CallFunction` as a `std.call_indirect` though
because it's more braindead to do it that way (it gets canonicalized to
a direct call easily).
2021-02-27 08:20:35 +08:00
|
|
|
if (kind == c10::prim::CallFunction) {
|
2021-03-02 09:24:15 +08:00
|
|
|
auto functionType = node->input(0)->type()->cast<c10::FunctionType>();
|
|
|
|
torch::jit::Block *calleeEntryBlock =
|
|
|
|
functionType->function()->graph()->block();
|
|
|
|
auto expectedTypes = c10::fmap(calleeEntryBlock->inputs(), [&](Value *v) {
|
|
|
|
return typeMapper.mapFromTorchType(loc, v->type());
|
|
|
|
});
|
|
|
|
MlirOperation operation = createMlirOperationAtEnd(
|
|
|
|
appendToBlock, "std.call_indirect", loc,
|
|
|
|
getMlirTypesFromValues(loc, node->outputs()),
|
|
|
|
lookupMappedValue(node->input(0)),
|
|
|
|
derefineValues(lookupMappedValues(node->inputs().slice(1)),
|
|
|
|
expectedTypes, loc, appendToBlock));
|
Properly import the entire torch::jit::CompilationUnit
This primarily unlocks proper handling of free functions (that is,
functions that are not methods of any torch.nn.Module).
Recommended review order:
- `ivalue_importer.cpp` + `ivalue_import/functions*.py`
- `GlobalizeObjectGraph.cpp` + test case
- misc other stuff
The `torch::jit::CompilationUnit` is basically a backing store or
"context" holding all the possible functions in the program. The
previous code was not explicitly accessing this data structure, since it
just imported the `torch::jit::Function`'s that it saw attached to
methods.
Subtly, any time a TorchScript module called into a free function, the
free function gets incorporated into the torch::jit::CompilationUnit,
but doesn't show up anywhere when dumping the module, except in the
curious pattern:
```
%5 : Function = prim::Constant[name="adaptive_avg_pool2d"]()
%6 : Tensor = prim::CallFunction(%5, %input.1, %4)
```
That is, calls are indirect calls, and are accessed via `prim::Constant`
materializing a function object. Even stranger, the `name` attribute here
doesn't really even tell the full story -- it doesn't correspond to
anything. It turns out that the c10::FunctionType itself actually holds
a pointer to the `torch::jit::Function` in the compilation unit
directly (so there is actually no indirection in prim::CallMethod,
because any two values of the same FunctionType call the same
function!). E.g. when converting the IR to bytecode, the "name" is
ignored [code link](https://github.com/pytorch/pytorch/blob/1d6bd157902d4b1347a5d03122d02b407658e263/torch/csrc/jit/runtime/interpreter.cpp#L937).
We do import `prim::CallFunction` as a `std.call_indirect` though
because it's more braindead to do it that way (it gets canonicalized to
a direct call easily).
2021-02-27 08:20:35 +08:00
|
|
|
mapResults(node, operation);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2021-02-02 09:59:42 +08:00
|
|
|
{
|
|
|
|
std::stringstream msg;
|
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
|
|
|
msg << "unhandled: could not import node: ";
|
2021-02-02 09:59:42 +08:00
|
|
|
node->print(msg, 0, nullptr);
|
|
|
|
mlirEmitError(getMlirLocationFromNode(context, node), msg.str().c_str());
|
|
|
|
throw mlir_diagnostic_emitted();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
MlirBlock NodeImporter::importBlock(Block *jitBlock,
|
2021-03-02 09:24:15 +08:00
|
|
|
CreateTerminatorFn createTerminator) {
|
2021-02-02 09:59:42 +08:00
|
|
|
MlirBlock block = createBlockFor(jitBlock);
|
|
|
|
for (Node *node : jitBlock->nodes()) {
|
|
|
|
importNode(node, block);
|
|
|
|
}
|
|
|
|
Node *returnNode = jitBlock->return_node();
|
2021-03-02 09:24:15 +08:00
|
|
|
createTerminator(lookupMappedValues(returnNode->inputs()), block);
|
2021-02-02 09:59:42 +08:00
|
|
|
return block;
|
|
|
|
}
|
|
|
|
|
|
|
|
MlirBlock NodeImporter::createBlockFor(Block *jitBlock) {
|
|
|
|
Node *paramNode = jitBlock->param_node();
|
|
|
|
MlirLocation loc = getMlirLocationFromNode(context, paramNode);
|
|
|
|
std::vector<MlirType> blockArgTypes =
|
|
|
|
getMlirTypesFromValues(loc, paramNode->outputs());
|
|
|
|
MlirBlock block = mlirBlockCreate(blockArgTypes.size(), blockArgTypes.data());
|
|
|
|
for (int i = 0, e = mlirBlockGetNumArguments(block); i < e; i++) {
|
|
|
|
Value *jitValue = paramNode->outputs()[i];
|
|
|
|
MlirValue value = mlirBlockGetArgument(block, i);
|
|
|
|
mapValue(jitValue, value);
|
|
|
|
}
|
|
|
|
return block;
|
|
|
|
}
|
|
|
|
|
|
|
|
void NodeImporter::mapValue(Value *jitValue, MlirValue value) {
|
|
|
|
auto it = valueMap.find(jitValue);
|
|
|
|
(void)it;
|
|
|
|
assert(it == valueMap.end() && "jitValue has already been mapped");
|
|
|
|
valueMap[jitValue] = value;
|
|
|
|
}
|
|
|
|
void NodeImporter::mapResults(Node *node, MlirOperation operation) {
|
|
|
|
assert(node->outputs().size() ==
|
|
|
|
(size_t)mlirOperationGetNumResults(operation));
|
|
|
|
for (int i = 0, e = node->outputs().size(); i < e; i++) {
|
|
|
|
mapValue(node->outputs()[i], mlirOperationGetResult(operation, i));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
MlirValue NodeImporter::lookupMappedValue(Value *jitValue) {
|
|
|
|
auto it = valueMap.find(jitValue);
|
|
|
|
assert(it != valueMap.end() &&
|
|
|
|
"trying to get mapping for jitValue that is not mapped yet!");
|
|
|
|
return it->second;
|
|
|
|
}
|
|
|
|
std::vector<MlirValue>
|
|
|
|
NodeImporter::lookupMappedValues(c10::ArrayRef<Value *> values) {
|
|
|
|
std::vector<MlirValue> ret;
|
|
|
|
for (Value *value : values) {
|
|
|
|
ret.push_back(lookupMappedValue(value));
|
|
|
|
}
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
MlirBlock torch_mlir::importBlock(MlirContext context, Block *jitBlock,
|
2021-03-02 09:24:15 +08:00
|
|
|
CreateTerminatorFn createTerminator) {
|
2021-02-02 09:59:42 +08:00
|
|
|
NodeImporter importer(context);
|
2021-03-02 09:24:15 +08:00
|
|
|
return importer.importBlock(jitBlock, createTerminator);
|
2021-02-02 09:59:42 +08:00
|
|
|
}
|