[llvm-branch-commits] [mlir] a55a0a3 - [mlir] Remove over specified memory effects
Andrew Young via llvm-branch-commits
llvm-branch-commits at lists.llvm.org
Thu Jan 14 14:50:07 PST 2021
Author: Andrew Young
Date: 2021-01-14T14:49:41-08:00
New Revision: a55a0a3056b8163d9e709b534bd737730fbb5d44
URL: https://github.com/llvm/llvm-project/commit/a55a0a3056b8163d9e709b534bd737730fbb5d44
DIFF: https://github.com/llvm/llvm-project/commit/a55a0a3056b8163d9e709b534bd737730fbb5d44.diff
LOG: [mlir] Remove over specified memory effects
The standard and gpu dialect both have `alloc` operations which use the
memory effect `MemAlloc`. In both cases, it is specified on both the
operation itself and on the result. This results in two memory effects
being created for these operations. When `MemAlloc` is defined on an
operation, it represents some background effect which the compiler
cannot reason about, and inhibits the ability of the compiler to
remove dead `std.alloc` operations. This change removes the uneeded
`MemAlloc` effect from these operations and leaves the effect on the
result, which allows dead allocs to be erased.
There is the same problem, but to a lesser extent, with MemFree, MemRead
and MemWrite. Over-specifying these traits is not currently inhibiting
any optimization.
Differential Revision: https://reviews.llvm.org/D94662
Added:
Modified:
mlir/docs/Interfaces.md
mlir/include/mlir/Dialect/GPU/GPUOps.td
mlir/include/mlir/Dialect/StandardOps/IR/Ops.td
mlir/test/Dialect/Linalg/sparse_1d.mlir
mlir/test/Dialect/Linalg/sparse_2d.mlir
mlir/test/Dialect/Linalg/sparse_3d.mlir
mlir/test/Transforms/canonicalize.mlir
Removed:
################################################################################
diff --git a/mlir/docs/Interfaces.md b/mlir/docs/Interfaces.md
index 4fe8421295ec..7f2920bae775 100644
--- a/mlir/docs/Interfaces.md
+++ b/mlir/docs/Interfaces.md
@@ -118,7 +118,7 @@ access to derived objects by providing a virtual interface that must be
implemented. As an example, many analyses and transformations want to reason
about the side effects of an operation to improve performance and correctness.
The side effects of an operation are generally tied to the semantics of a
-specific operation, for example an `affine.load` operation has a `write` effect
+specific operation, for example an `affine.load` operation has a `read` effect
(as the name may suggest).
These interfaces are defined by overriding the
diff --git a/mlir/include/mlir/Dialect/GPU/GPUOps.td b/mlir/include/mlir/Dialect/GPU/GPUOps.td
index 457477f7f3c1..915347e0647e 100644
--- a/mlir/include/mlir/Dialect/GPU/GPUOps.td
+++ b/mlir/include/mlir/Dialect/GPU/GPUOps.td
@@ -806,8 +806,7 @@ def GPU_WaitOp : GPU_Op<"wait", [GPU_AsyncOpInterface]> {
def GPU_AllocOp : GPU_Op<"alloc", [
GPU_AsyncOpInterface,
- AttrSizedOperandSegments,
- MemoryEffects<[MemAlloc<DefaultResource>]>
+ AttrSizedOperandSegments
]> {
let summary = "GPU memory allocation operation.";
@@ -831,7 +830,7 @@ def GPU_AllocOp : GPU_Op<"alloc", [
let arguments = (ins Variadic<GPU_AsyncToken>:$asyncDependencies,
Variadic<Index>:$dynamicSizes, Variadic<Index>:$symbolOperands);
- let results = (outs Res<AnyMemRef, "", [MemAlloc<DefaultResource>]>:$memref,
+ let results = (outs Res<AnyMemRef, "", [MemAlloc]>:$memref,
Optional<GPU_AsyncToken>:$asyncToken);
let extraClassDeclaration = [{
@@ -844,9 +843,7 @@ def GPU_AllocOp : GPU_Op<"alloc", [
}];
}
-def GPU_DeallocOp : GPU_Op<"dealloc", [
- GPU_AsyncOpInterface, MemoryEffects<[MemFree]>
- ]> {
+def GPU_DeallocOp : GPU_Op<"dealloc", [GPU_AsyncOpInterface]> {
let summary = "GPU memory deallocation operation";
@@ -879,9 +876,7 @@ def GPU_DeallocOp : GPU_Op<"dealloc", [
}];
}
-def GPU_MemcpyOp : GPU_Op<"memcpy", [
- GPU_AsyncOpInterface, MemoryEffects<[MemRead, MemWrite]>
- ]> {
+def GPU_MemcpyOp : GPU_Op<"memcpy", [GPU_AsyncOpInterface]> {
let summary = "GPU memcpy operation";
diff --git a/mlir/include/mlir/Dialect/StandardOps/IR/Ops.td b/mlir/include/mlir/Dialect/StandardOps/IR/Ops.td
index 3ae7ad54b80f..6eabe1179234 100644
--- a/mlir/include/mlir/Dialect/StandardOps/IR/Ops.td
+++ b/mlir/include/mlir/Dialect/StandardOps/IR/Ops.td
@@ -170,7 +170,6 @@ class AllocLikeOp<string mnemonic,
list<OpTrait> traits = []> :
Std_Op<mnemonic,
!listconcat([
- MemoryEffects<[MemAlloc<resource>]>,
AttrSizedOperandSegments
], traits)> {
@@ -1507,8 +1506,7 @@ def SinOp : FloatUnaryOp<"sin"> {
// DeallocOp
//===----------------------------------------------------------------------===//
-def DeallocOp : Std_Op<"dealloc",
- [MemoryEffects<[MemFree]>, MemRefsNormalizable]> {
+def DeallocOp : Std_Op<"dealloc", [MemRefsNormalizable]> {
let summary = "memory deallocation operation";
let description = [{
The `dealloc` operation frees the region of memory referenced by a memref
diff --git a/mlir/test/Dialect/Linalg/sparse_1d.mlir b/mlir/test/Dialect/Linalg/sparse_1d.mlir
index 0d471244f77a..9f7fbe471409 100644
--- a/mlir/test/Dialect/Linalg/sparse_1d.mlir
+++ b/mlir/test/Dialect/Linalg/sparse_1d.mlir
@@ -863,7 +863,6 @@ func @two_way_inv_alt(%arga: tensor<16xf32>,
// CHECK: %[[VAL_3:.*]] = constant 0 : index
// CHECK: %[[VAL_4:.*]] = constant 1 : index
// CHECK: %[[VAL_5:.*]] = alloca(%[[VAL_2]]) : memref<?xindex>
-// CHECK: %[[VAL_6:.*]] = alloca(%[[VAL_2]]) : memref<?xindex>
// CHECK: %[[VAL_7:.*]] = alloca(%[[VAL_2]]) : memref<?xf32>
// CHECK: %[[VAL_8:.*]] = alloca() : memref<f32>
// CHECK: %[[VAL_9:.*]] = load %[[VAL_5]]{{\[}}%[[VAL_3]]] : memref<?xindex>
diff --git a/mlir/test/Dialect/Linalg/sparse_2d.mlir b/mlir/test/Dialect/Linalg/sparse_2d.mlir
index 57805777eb46..957c3b6e1589 100644
--- a/mlir/test/Dialect/Linalg/sparse_2d.mlir
+++ b/mlir/test/Dialect/Linalg/sparse_2d.mlir
@@ -1091,7 +1091,6 @@ func @matvec(%argA: tensor<16x32xf32>, %argb: tensor<32xf32>, %argx: tensor<16xf
// CHECK: %[[VAL_4:.*]] = constant 0 : index
// CHECK: %[[VAL_5:.*]] = constant 1 : index
// CHECK: %[[VAL_6:.*]] = alloca(%[[VAL_2]]) : memref<?xindex>
-// CHECK: %[[VAL_7:.*]] = alloca(%[[VAL_2]]) : memref<?xindex>
// CHECK: %[[VAL_8:.*]] = alloca(%[[VAL_2]]) : memref<?xf32>
// CHECK: %[[VAL_9:.*]] = alloca() : memref<f32>
// CHECK: scf.for %[[VAL_10:.*]] = %[[VAL_4]] to %[[VAL_3]] step %[[VAL_5]] {
diff --git a/mlir/test/Dialect/Linalg/sparse_3d.mlir b/mlir/test/Dialect/Linalg/sparse_3d.mlir
index 629a99d0a864..02ee2a8b1740 100644
--- a/mlir/test/Dialect/Linalg/sparse_3d.mlir
+++ b/mlir/test/Dialect/Linalg/sparse_3d.mlir
@@ -1260,11 +1260,8 @@ func @kernel_3d(%arga: tensor<?x?xf32>,
// CHECK: %[[VAL_3:.*]] = constant 0 : index
// CHECK: %[[VAL_4:.*]] = constant 1 : index
// CHECK: %[[VAL_5:.*]] = alloca(%[[VAL_2]]) : memref<?xindex>
-// CHECK: %[[VAL_6:.*]] = alloca(%[[VAL_2]]) : memref<?xindex>
// CHECK: %[[VAL_7:.*]] = alloca(%[[VAL_2]]) : memref<?xindex>
-// CHECK: %[[VAL_8:.*]] = alloca(%[[VAL_2]]) : memref<?xindex>
// CHECK: %[[VAL_9:.*]] = alloca(%[[VAL_2]]) : memref<?xindex>
-// CHECK: %[[VAL_10:.*]] = alloca(%[[VAL_2]]) : memref<?xindex>
// CHECK: %[[VAL_11:.*]] = alloca(%[[VAL_2]]) : memref<?xf32>
// CHECK: %[[VAL_12:.*]] = alloca() : memref<f32>
// CHECK: %[[VAL_13:.*]] = load %[[VAL_5]]{{\[}}%[[VAL_3]]] : memref<?xindex>
diff --git a/mlir/test/Transforms/canonicalize.mlir b/mlir/test/Transforms/canonicalize.mlir
index e3e4b56fd072..5b6f8cde9fec 100644
--- a/mlir/test/Transforms/canonicalize.mlir
+++ b/mlir/test/Transforms/canonicalize.mlir
@@ -415,7 +415,7 @@ func @dead_block_elim() {
}
// CHECK-LABEL: func @dyn_shape_fold(%arg0: index, %arg1: index)
-func @dyn_shape_fold(%L : index, %M : index) -> (memref<? x ? x i32>, memref<? x ? x f32>) {
+func @dyn_shape_fold(%L : index, %M : index) -> (memref<? x ? x i32>, memref<? x ? x f32>, memref<4 x ? x 8 x ? x ? x f32>) {
// CHECK: %c0 = constant 0 : index
%zero = constant 0 : index
// The constants below disappear after they propagate into shapes.
@@ -449,7 +449,7 @@ func @dyn_shape_fold(%L : index, %M : index) -> (memref<? x ? x i32>, memref<? x
}
}
- return %c, %d : memref<? x ? x i32>, memref<? x ? x f32>
+ return %c, %d, %e : memref<? x ? x i32>, memref<? x ? x f32>, memref<4 x ? x 8 x ? x ? x f32>
}
#map1 = affine_map<(d0, d1)[s0, s1, s2] -> (d0 * s1 + s0 + d1 * s2)>
More information about the llvm-branch-commits
mailing list