llvm
/
torch-mlir
mirror of https://github.com/llvm/torch-mlir
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
torch-mlir/test/Dialect/Torch/GlobalizeObjectGraph/basic.mlir

44 lines
1.7 KiB
MLIR
Raw Normal View History

Implement GlobalizeObjectGraph transformation. This required restructuring of how we model TorchScript on import. The main difference is that now we split out a `torch.class_type` that holds methods and declarations of the types of each slot. This is more consistent with TorchScript (our previous representation was "denormalized"). Recommended reading order: 1. check out the description of `torch.class_type` in `TorchOps.td` and look at `test/Dialect/Torch/ops.mlir` and `frontends/pytorch/test/module_import/` to familiarize with the new representation. - Just look at the new IR. The diff between the old names and new names is confusing. 2. check out `test/Dialect/Torch/globalize-object-graph*.mlir` and read along with the pass description in `include/npcomp/Dialect/Torch/Transforms/Passes.td` 3. Read the code in `GlobalizeObjectGraph.cpp` and miscellaneous changes in `ivalue_importer.cpp`, `TorchOps.cpp`, etc.
2021-02-18 03:28:51 +08:00
// RUN: npcomp-opt -torch-globalize-object-graph -split-input-file %s | FileCheck %s
// Basic case.
Give torch.global_slot an initializer region. This is a much simpler representation than the ad-hoc initializer function we had before. It is also less general, but given the rationale in Passes.td it seems like the right tradeoff right now. We can probably carry this representation for quite a while, and when we can't, it likely means that TorchScript has fixed their object identity bug and we probably need to just upgrade to a more general object graph modeling (more general than GlobalizeObjectGraph). In particular, we don't want to deal with defining and carrying around this initializer function concept until we need it. For example, if we want to constant-fold the global slots into uses, this is a much better representation, and it plays better with symbol-dce (the initializer function counts as a "use" of the symbol). (the alternative would have been to write a pass that converts the initializer function to this form when possible, but I realized that lots of information had been lost which made that fairly annoying -- it was all self-inflicted anyway, so best to just go to the source (GlobalizeObjectGraph) before the information is lost) Now symbol-dce works nicely (no more "training" bools) ``` pt_util ~/tmp/classifier.pt --import --exported-name forward \ | npcomp-opt -torch-globalize-object-graph -inline -symbol-dce ``` IR: https://gist.github.com/silvasean/8abe63d70d24e29d6db9170ccc8d512b
2021-02-26 07:54:51 +08:00
// CHECK-LABEL: torch.global_slot @b : !basicpy.BoolType {
// CHECK: %[[INIT:.*]] = basicpy.bool_constant true
// CHECK: torch.global_slot.init %[[INIT]] : !basicpy.BoolType
// CHECK: }
// CHECK-LABEL: torch.global_slot @i : i64 {
// CHECK: %[[INIT:.*]] = basicpy.numeric_constant 3 : i64
// CHECK: torch.global_slot.init %[[INIT]] : i64
// CHECK: }
// CHECK-LABEL: torch.global_slot @f : f64 {
// CHECK: %[[INIT:.*]] = basicpy.numeric_constant 4.250000e+01 : f64
// CHECK: torch.global_slot.init %[[INIT]] : f64
// CHECK: }
Implement GlobalizeObjectGraph transformation. This required restructuring of how we model TorchScript on import. The main difference is that now we split out a `torch.class_type` that holds methods and declarations of the types of each slot. This is more consistent with TorchScript (our previous representation was "denormalized"). Recommended reading order: 1. check out the description of `torch.class_type` in `TorchOps.td` and look at `test/Dialect/Torch/ops.mlir` and `frontends/pytorch/test/module_import/` to familiarize with the new representation. - Just look at the new IR. The diff between the old names and new names is confusing. 2. check out `test/Dialect/Torch/globalize-object-graph*.mlir` and read along with the pass description in `include/npcomp/Dialect/Torch/Transforms/Passes.td` 3. Read the code in `GlobalizeObjectGraph.cpp` and miscellaneous changes in `ivalue_importer.cpp`, `TorchOps.cpp`, etc.
2021-02-18 03:28:51 +08:00
Give torch.global_slot an initializer region. This is a much simpler representation than the ad-hoc initializer function we had before. It is also less general, but given the rationale in Passes.td it seems like the right tradeoff right now. We can probably carry this representation for quite a while, and when we can't, it likely means that TorchScript has fixed their object identity bug and we probably need to just upgrade to a more general object graph modeling (more general than GlobalizeObjectGraph). In particular, we don't want to deal with defining and carrying around this initializer function concept until we need it. For example, if we want to constant-fold the global slots into uses, this is a much better representation, and it plays better with symbol-dce (the initializer function counts as a "use" of the symbol). (the alternative would have been to write a pass that converts the initializer function to this form when possible, but I realized that lots of information had been lost which made that fairly annoying -- it was all self-inflicted anyway, so best to just go to the source (GlobalizeObjectGraph) before the information is lost) Now symbol-dce works nicely (no more "training" bools) ``` pt_util ~/tmp/classifier.pt --import --exported-name forward \ | npcomp-opt -torch-globalize-object-graph -inline -symbol-dce ``` IR: https://gist.github.com/silvasean/8abe63d70d24e29d6db9170ccc8d512b
2021-02-26 07:54:51 +08:00
// CHECK-LABEL: torch.global_slot @a : !numpy.ndarray<*:!numpy.any_dtype> {
Implement GlobalizeObjectGraph transformation. This required restructuring of how we model TorchScript on import. The main difference is that now we split out a `torch.class_type` that holds methods and declarations of the types of each slot. This is more consistent with TorchScript (our previous representation was "denormalized"). Recommended reading order: 1. check out the description of `torch.class_type` in `TorchOps.td` and look at `test/Dialect/Torch/ops.mlir` and `frontends/pytorch/test/module_import/` to familiarize with the new representation. - Just look at the new IR. The diff between the old names and new names is confusing. 2. check out `test/Dialect/Torch/globalize-object-graph*.mlir` and read along with the pass description in `include/npcomp/Dialect/Torch/Transforms/Passes.td` 3. Read the code in `GlobalizeObjectGraph.cpp` and miscellaneous changes in `ivalue_importer.cpp`, `TorchOps.cpp`, etc.
2021-02-18 03:28:51 +08:00
// CHECK: %[[C:.*]] = constant dense<1.000000e+00> : tensor<1xf32>
Give torch.global_slot an initializer region. This is a much simpler representation than the ad-hoc initializer function we had before. It is also less general, but given the rationale in Passes.td it seems like the right tradeoff right now. We can probably carry this representation for quite a while, and when we can't, it likely means that TorchScript has fixed their object identity bug and we probably need to just upgrade to a more general object graph modeling (more general than GlobalizeObjectGraph). In particular, we don't want to deal with defining and carrying around this initializer function concept until we need it. For example, if we want to constant-fold the global slots into uses, this is a much better representation, and it plays better with symbol-dce (the initializer function counts as a "use" of the symbol). (the alternative would have been to write a pass that converts the initializer function to this form when possible, but I realized that lots of information had been lost which made that fairly annoying -- it was all self-inflicted anyway, so best to just go to the source (GlobalizeObjectGraph) before the information is lost) Now symbol-dce works nicely (no more "training" bools) ``` pt_util ~/tmp/classifier.pt --import --exported-name forward \ | npcomp-opt -torch-globalize-object-graph -inline -symbol-dce ``` IR: https://gist.github.com/silvasean/8abe63d70d24e29d6db9170ccc8d512b
2021-02-26 07:54:51 +08:00
// CHECK: %[[A:.*]] = numpy.create_array_from_tensor %[[C]] : (tensor<1xf32>) -> !numpy.ndarray<*:!numpy.any_dtype>
// CHECK: torch.global_slot.init %[[A]] : !numpy.ndarray<*:!numpy.any_dtype>
// CHECK: }
Implement GlobalizeObjectGraph transformation. This required restructuring of how we model TorchScript on import. The main difference is that now we split out a `torch.class_type` that holds methods and declarations of the types of each slot. This is more consistent with TorchScript (our previous representation was "denormalized"). Recommended reading order: 1. check out the description of `torch.class_type` in `TorchOps.td` and look at `test/Dialect/Torch/ops.mlir` and `frontends/pytorch/test/module_import/` to familiarize with the new representation. - Just look at the new IR. The diff between the old names and new names is confusing. 2. check out `test/Dialect/Torch/globalize-object-graph*.mlir` and read along with the pass description in `include/npcomp/Dialect/Torch/Transforms/Passes.td` 3. Read the code in `GlobalizeObjectGraph.cpp` and miscellaneous changes in `ivalue_importer.cpp`, `TorchOps.cpp`, etc.
2021-02-18 03:28:51 +08:00
torch.class_type @c {
torch.attr "b" : !basicpy.BoolType
torch.attr "i" : i64
torch.attr "f" : f64
torch.attr "a" : !numpy.ndarray<*:!numpy.any_dtype>
}
%bool_true = basicpy.bool_constant true
%i = basicpy.numeric_constant 3 : i64
%f = basicpy.numeric_constant 4.250000e+01 : f64
%cst = constant dense<1.000000e+00> : tensor<1xf32>
%a = numpy.create_array_from_tensor %cst : (tensor<1xf32>) -> !numpy.ndarray<*:!numpy.any_dtype>
torch.nn_module {
torch.slot "b", %bool_true : !basicpy.BoolType
torch.slot "i", %i : i64
torch.slot "f", %f : f64
torch.slot "a", %a : !numpy.ndarray<*:!numpy.any_dtype>
} : !torch.nn.Module<"c">