llvm
/
torch-mlir
mirror of https://github.com/llvm/torch-mlir
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
torch-mlir/frontends/pytorch/csrc/builder/op_builder.cpp

30 lines
1010 B
C++
Raw Normal View History

Add support for prim::GetAttr/SetAttr/CallMethod/If This required some invasive surgery to graph_importer.h/cpp, specifically moving most of it into node_importer.h/cpp and relayering it. The abstraction that it had didn't work well in the recursive setting that happens with prim::If. The key observation is that torch::jit::Graph doesn't really correspond directly to anything on the MLIR side. It's a weird combination of a context, builder, and function and just holds a `torch::jit::Block`. It is `torch::jit::Node` and `torch::jit::Block` which form the recursive structure analogous to MLIR's operation/region/block. So node_importer.h/cpp makes sense as a core building block. As part of doing this, I did venture a bit into the AcapController code, and realize now that there is functionality duplicated there with the ivalue importer. Will refactor that soon.
2021-02-02 09:59:42 +08:00
//===- op_builder.cpp -----------------------------------------------------===//
//
// This file is licensed under a pytorch-style license
// See frontends/pytorch/LICENSE for license information.
//
//===----------------------------------------------------------------------===//
#include "op_builder.h"
#include "mlir-c/BuiltinAttributes.h"
#include "mlir-c/BuiltinTypes.h"
#include "mlir-c/Diagnostics.h"
Make C API files more consistent - Make consistent with MLIR Core - Use `//` or `///` comments. - Use `bool` type for booleans - No duplicated comments in .cpp files - Split types into separate files `{Basicpy,Numpy,Torch}Types.h` - Add dialect prefix consistently to C API symbols. We have lots of similarly named types (e.g. "list" type in basicpy and torch).
2021-06-15 05:13:59 +08:00
#include "npcomp-c/BasicpyTypes.h"
#include "npcomp-c/TorchTypes.h"
Add support for prim::GetAttr/SetAttr/CallMethod/If This required some invasive surgery to graph_importer.h/cpp, specifically moving most of it into node_importer.h/cpp and relayering it. The abstraction that it had didn't work well in the recursive setting that happens with prim::If. The key observation is that torch::jit::Graph doesn't really correspond directly to anything on the MLIR side. It's a weird combination of a context, builder, and function and just holds a `torch::jit::Block`. It is `torch::jit::Node` and `torch::jit::Block` which form the recursive structure analogous to MLIR's operation/region/block. So node_importer.h/cpp makes sense as a core building block. As part of doing this, I did venture a bit into the AcapController code, and realize now that there is functionality duplicated there with the ivalue importer. Will refactor that soon.
2021-02-02 09:59:42 +08:00
using namespace torch_mlir;
OpBuilder::OpBuilder(MlirContext context) : context(context) {}
MlirOperation OpBuilder::createNoneConstant(MlirLocation loc) {
Introduce native `!torch.none` type. - Add `torch.constant.none` op to construct it (naming is chosen to be analogous to Torch's representation of a prim::Constant with NoneType, rather than using the "singleton" terminology of Basicpy).
2021-06-15 02:36:10 +08:00
return createMlirOperation("torch.constant.none", loc,
npcompTorchNoneTypeGet(context));
Add support for prim::GetAttr/SetAttr/CallMethod/If This required some invasive surgery to graph_importer.h/cpp, specifically moving most of it into node_importer.h/cpp and relayering it. The abstraction that it had didn't work well in the recursive setting that happens with prim::If. The key observation is that torch::jit::Graph doesn't really correspond directly to anything on the MLIR side. It's a weird combination of a context, builder, and function and just holds a `torch::jit::Block`. It is `torch::jit::Node` and `torch::jit::Block` which form the recursive structure analogous to MLIR's operation/region/block. So node_importer.h/cpp makes sense as a core building block. As part of doing this, I did venture a bit into the AcapController code, and realize now that there is functionality duplicated there with the ivalue importer. Will refactor that soon.
2021-02-02 09:59:42 +08:00
}
MlirOperation OpBuilder::createBoolConstant(MlirLocation loc, bool value) {
return createMlirOperation(
Make C API files more consistent - Make consistent with MLIR Core - Use `//` or `///` comments. - Use `bool` type for booleans - No duplicated comments in .cpp files - Split types into separate files `{Basicpy,Numpy,Torch}Types.h` - Add dialect prefix consistently to C API symbols. We have lots of similarly named types (e.g. "list" type in basicpy and torch).
2021-06-15 05:13:59 +08:00
"basicpy.bool_constant", loc, npcompBasicpyBoolTypeGet(context),
Add support for prim::GetAttr/SetAttr/CallMethod/If This required some invasive surgery to graph_importer.h/cpp, specifically moving most of it into node_importer.h/cpp and relayering it. The abstraction that it had didn't work well in the recursive setting that happens with prim::If. The key observation is that torch::jit::Graph doesn't really correspond directly to anything on the MLIR side. It's a weird combination of a context, builder, and function and just holds a `torch::jit::Block`. It is `torch::jit::Node` and `torch::jit::Block` which form the recursive structure analogous to MLIR's operation/region/block. So node_importer.h/cpp makes sense as a core building block. As part of doing this, I did venture a bit into the AcapController code, and realize now that there is functionality duplicated there with the ivalue importer. Will refactor that soon.
2021-02-02 09:59:42 +08:00
toMlirNamedAttribute("value", mlirBoolAttrGet(context, value)));
}