master

GGitHub[mlir] New canonicalization patterns for shape.shape_of and tensor.reshape (#98531)

38d0b2d1创建于 2024年7月19日历史提交

文件	最后提交记录	最后更新时间
IR	[mlir] New canonicalization patterns for shape.shape_of and tensor.reshape (#98531) This PR includes 3 new canonicalization patterns: - Operation shape.shape_of: shape of reshape // Before func.func @f(%arg0: tensor<*xf32>, %arg1: tensor<?xindex>) -> tensor<?xindex> { %reshape = tensor.reshape %arg0(%arg1) : (tensor<*xf32>, tensor<?xindex>) -> tensor<*xf32> %0 = shape.shape_of %reshape : tensor<*xf32> -> tensor<?xindex> return %0 : tensor<?xindex> } // After func.func @f(%arg0: tensor<*xf32>, %arg1: tensor<?xindex>) -> tensor<?xindex> { return %arg1 : tensor<?xindex> } - Operation tensor.reshape: reshape of reshape // Before func.func @fold_tensor_reshape(%arg0: tensor<*xf32>, %arg1: tensor<?xindex>, %arg2: tensor<?xindex>) -> tensor<*xf32> { %0 = tensor.reshape %arg0(%arg1) : (tensor<*xf32>, tensor<?xindex>) -> tensor<*xf32> %1 = tensor.reshape %0(%arg2) : (tensor<*xf32>, tensor<?xindex>) -> tensor<*xf32> return %1 : tensor<*xf32> } // After func.func @fold_tensor_reshape(%arg0: tensor<*xf32>, %arg1: tensor<?xindex>, %arg2: tensor<?xindex>) -> tensor<*xf32> { %reshape = tensor.reshape %arg0(%arg2) : (tensor<*xf32>, tensor<?xindex>) -> tensor<*xf32> return %reshape : tensor<*xf32> } - Operation tensor.reshape: reshape 1D to 1D // Before func.func @fold_reshape_1d(%input: tensor<?xf32>, %shape: tensor<1xindex>) -> tensor<?xf32> { %0 = tensor.reshape %input(%shape) : (tensor<?xf32>, tensor<1xindex>) -> tensor<?xf32> return %0 : tensor<?xf32> } // After func.func @fold_reshape_1d(%arg0: tensor<?xf32>, %arg1: tensor<1xindex>) -> tensor<?xf32> { return %arg0 : tensor<?xf32> } These three canonicalization patterns cooperate to simplify the IR structure emerging from the lowering of certain element-wise ops with unranked tensor inputs. See file unranked-tensor-lowering.mlir in the proposed change list for a detailed example and description. For context, this PR is meant to enable code optimizations for the code generated while lowering ops quant.qcast and quant.dcast with unranked tensors, as proposed in https://discourse.llvm.org/t/rfc-improvements-in-the-quant-dialect/79942 (implementation currently in progress).	2 年前
TransformOps	[mlir][tensor] Implement constant folder for tensor.pad (#92691) Extend the folding ability of the RewriteAsConstant patterns to include tensor.pad operations on constants. The new pattern with constant fold tensor.pad operations which operate on tensor constants and have statically resolvable padding sizes/values. %init = arith.constant dense<[[6, 7], [8, 9]]> : tensor<2x2xi32> %pad_value = arith.constant 0 : i32 %0 = tensor.pad %init low[1, 1] high[1, 1] { ^bb0(%arg1: index, %arg2: index): tensor.yield %pad_value : i32 } : tensor<2x2xi32> to tensor<4x4xi32> becomes %cst = arith.constant dense<[[0, 0, 0, 0], [0, 6, 7, 0], [0, 8, 9, 0], [0, 0, 0, 0]]> : tensor<4x4xi32> Co-authored-by: Spenser Bauman <sabauma@fastmail>	2 年前
Transforms	[mlir][Tensor] Add pattern to fold concats of empty. (#98994) A concatenation of empty tensors can be replaced by a single empty tensor of the concatenated shape. Add this pattern to populateFoldTensorEmptyPatterns.	2 年前
Utils	[mlir][tensor][NFC] Move function comments to where they are declared. (#94002) According to LLVM style guide, we prefer putting the documentation comments for public APIs into the header file. See https://llvm.org/docs/CodingStandards.html#doxygen-use-in-documentation-comments for more details.	2 年前
CMakeLists.txt	[mlir][transform] Add TrackingListener This change makes it possible to use a greedy pattern rewrite as part of a transform op, even if the transform op does not invalidate the target handle (in particular transform ops without FunctionalStyleTransformOpTrait) and the targeted op is not isolated from above. The listener API allows us to track replacements of ops with values, but not ops with ops. Therefore, the TrackingListener is conservative: If an op is replaced with values that all have the same defining op and the defining op is of the same type as the original op, it is safe to assume that the op was replaced with an equivalent op. Otherwise, the op mapping is dropped. When this is not good enough, transforms can track values instead or provide a custom findReplacementOp function. Differential Revision: https://reviews.llvm.org/D147039	3 年前