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/npcomp-run-mlir/matmul.mlir

33 lines
1.3 KiB
MLIR
Raw Normal View History

[RefE2E] Add support for matmul. I'm pretty happy with how this turned out. It looks pretty much like it should -- one change at each layer. This particular op bottoms out on linalg which takes care of the rest. - Add tcf.matmul - Add tcp.matmul - Add TCF->TCP lowering - Add tcp.matmul shape transfer function (BypassShapes.cpp) - Add tcp.matmul -> linalg.matmul lowering (LowerShapedResultsToMemref.cpp) - Add support to LowerShapeConstraints for lowering the new shape.cstr_require This matmul op is pretty limited in its capabilities. There is no batching and no multidimensional contraction. Certainly more design work will be needed to find the right abstractions that aren't too general but also help to canonicalize many cases from frontends. This is mainly to show that adding a new op needn't be very "scary" once we have the e2e infra in place. Also, - this clears out some exploratory cruft from the TCF dialect now that this is starting to become real.
2020-09-18 09:56:01 +08:00
// RUN: npcomp-run-mlir %s \
// RUN: -invoke matmul \
// RUN: -arg-value="dense<[[1.0, 0.0, 1.0], [1.0, 1.0, 1.0]]> : tensor<2x3xf32>" \
// RUN: -arg-value="dense<[[1.0, 2.0], [3.0, 4.0], [5.0, 6.0]]> : tensor<3x2xf32>" \
// RUN: -shared-libs=%npcomp_runtime_shlib 2>&1 \
// RUN: | FileCheck %s
[RefE2E] Initialize the linalg matmul accumulator buffer. I was seeing some miscompiles due to the uninitialized data read here before. Interestingly, this was masked in some of our previous test cases, since the uninitialized data "always" was so small that it would present as a rounding error for the 1.0-10.0 sized values that the matmul was computing on.
2020-10-03 03:30:59 +08:00
// RUN: npcomp-run-mlir %s \
// RUN: -invoke matmul \
// RUN: -arg-value="dense<0.0> : tensor<2x3xf32>" \
// RUN: -arg-value="dense<0.0> : tensor<3x2xf32>" \
// RUN: -shared-libs=%npcomp_runtime_shlib 2>&1 \
// RUN: | FileCheck %s --check-prefix=ZEROS
[RefE2E] Add support for matmul. I'm pretty happy with how this turned out. It looks pretty much like it should -- one change at each layer. This particular op bottoms out on linalg which takes care of the rest. - Add tcf.matmul - Add tcp.matmul - Add TCF->TCP lowering - Add tcp.matmul shape transfer function (BypassShapes.cpp) - Add tcp.matmul -> linalg.matmul lowering (LowerShapedResultsToMemref.cpp) - Add support to LowerShapeConstraints for lowering the new shape.cstr_require This matmul op is pretty limited in its capabilities. There is no batching and no multidimensional contraction. Certainly more design work will be needed to find the right abstractions that aren't too general but also help to canonicalize many cases from frontends. This is mainly to show that adding a new op needn't be very "scary" once we have the e2e infra in place. Also, - this clears out some exploratory cruft from the TCF dialect now that this is starting to become real.
2020-09-18 09:56:01 +08:00
// Basic correctness check:
// [1 0 1] * [1 2] = [6 8]
// [1 1 1] [3 4] [9 12]
// [5 6]
// CHECK: output #0: dense<[
// CHECK-SAME: [6.000000e+00, 8.000000e+00], [9.000000e+00, 1.200000e+01]
// CHECK-SAME: ]> : tensor<2x2xf32>
[RefE2E] Initialize the linalg matmul accumulator buffer. I was seeing some miscompiles due to the uninitialized data read here before. Interestingly, this was masked in some of our previous test cases, since the uninitialized data "always" was so small that it would present as a rounding error for the 1.0-10.0 sized values that the matmul was computing on.
2020-10-03 03:30:59 +08:00
// Check with zeros as well. The result should be identically zeros.
// If any uninitialized data sneaks in (even very small values that would be
// rounding errors for the test case above), it will show up here.
// ZEROS: output #0: dense<0.000000e+00> : tensor<2x2xf32>
[RefE2E] Add support for matmul. I'm pretty happy with how this turned out. It looks pretty much like it should -- one change at each layer. This particular op bottoms out on linalg which takes care of the rest. - Add tcf.matmul - Add tcp.matmul - Add TCF->TCP lowering - Add tcp.matmul shape transfer function (BypassShapes.cpp) - Add tcp.matmul -> linalg.matmul lowering (LowerShapedResultsToMemref.cpp) - Add support to LowerShapeConstraints for lowering the new shape.cstr_require This matmul op is pretty limited in its capabilities. There is no batching and no multidimensional contraction. Certainly more design work will be needed to find the right abstractions that aren't too general but also help to canonicalize many cases from frontends. This is mainly to show that adding a new op needn't be very "scary" once we have the e2e infra in place. Also, - this clears out some exploratory cruft from the TCF dialect now that this is starting to become real.
2020-09-18 09:56:01 +08:00
func @matmul(%arg0: tensor<?x?xf32>, %arg1: tensor<?x?xf32>) -> tensor<?x?xf32> {
%0 = tcf.matmul %arg0, %arg1 : (tensor<?x?xf32>, tensor<?x?xf32>) -> tensor<?x?xf32>
return %0 : tensor<?x?xf32>
}