[mlir][vector] Remove remaining bitwidths from linearization patterns #138072
Conversation
|
✅ With the latest revision this PR passed the C/C++ code formatter. |
|
@llvm/pr-subscribers-mlir-vector @llvm/pr-subscribers-mlir Author: James Newling (newling) ChangesIn #136581 the bitwidth logic was supposed to be completely removed from the linearization patterns. But it was left in a few places. This PR removes the remainders (they were default valued constructor arguments that were unused). Full diff: https://github.com/llvm/llvm-project/pull/138072.diff 1 Files Affected:
diff --git a/mlir/lib/Dialect/Vector/Transforms/VectorLinearize.cpp b/mlir/lib/Dialect/Vector/Transforms/VectorLinearize.cpp
index 67e15852dc5ea..b9fdede535112 100644
--- a/mlir/lib/Dialect/Vector/Transforms/VectorLinearize.cpp
+++ b/mlir/lib/Dialect/Vector/Transforms/VectorLinearize.cpp
@@ -21,7 +21,6 @@
#include "mlir/Transforms/DialectConversion.h"
#include "llvm/ADT/ArrayRef.h"
#include <cstdint>
-#include <limits>
#include <numeric>
#include <optional>
@@ -230,10 +229,8 @@ struct LinearizeVectorExtractStridedSlice final
struct LinearizeVectorShuffle final
: public OpConversionPattern<vector::ShuffleOp> {
using OpConversionPattern::OpConversionPattern;
- LinearizeVectorShuffle(
- const TypeConverter &typeConverter, MLIRContext *context,
- unsigned targetVectBitWidth = std::numeric_limits<unsigned>::max(),
- PatternBenefit benefit = 1)
+ LinearizeVectorShuffle(const TypeConverter &typeConverter,
+ MLIRContext *context, PatternBenefit benefit = 1)
: OpConversionPattern(typeConverter, context, benefit) {}
LogicalResult
@@ -290,10 +287,8 @@ struct LinearizeVectorShuffle final
struct LinearizeVectorExtract final
: public OpConversionPattern<vector::ExtractOp> {
using OpConversionPattern::OpConversionPattern;
- LinearizeVectorExtract(
- const TypeConverter &typeConverter, MLIRContext *context,
- unsigned targetVectBitWidth = std::numeric_limits<unsigned>::max(),
- PatternBenefit benefit = 1)
+ LinearizeVectorExtract(const TypeConverter &typeConverter,
+ MLIRContext *context, PatternBenefit benefit = 1)
: OpConversionPattern(typeConverter, context, benefit) {}
LogicalResult
matchAndRewrite(vector::ExtractOp extractOp, OpAdaptor adaptor,
@@ -339,10 +334,8 @@ struct LinearizeVectorExtract final
struct LinearizeVectorInsert final
: public OpConversionPattern<vector::InsertOp> {
using OpConversionPattern::OpConversionPattern;
- LinearizeVectorInsert(
- const TypeConverter &typeConverter, MLIRContext *context,
- unsigned targetVectBitWidth = std::numeric_limits<unsigned>::max(),
- PatternBenefit benefit = 1)
+ LinearizeVectorInsert(const TypeConverter &typeConverter,
+ MLIRContext *context, PatternBenefit benefit = 1)
: OpConversionPattern(typeConverter, context, benefit) {}
LogicalResult
matchAndRewrite(vector::InsertOp insertOp, OpAdaptor adaptor,
@@ -408,10 +401,8 @@ struct LinearizeVectorInsert final
struct LinearizeVectorBitCast final
: public OpConversionPattern<vector::BitCastOp> {
using OpConversionPattern::OpConversionPattern;
- LinearizeVectorBitCast(
- const TypeConverter &typeConverter, MLIRContext *context,
- unsigned targetVectBitWidth = std::numeric_limits<unsigned>::max(),
- PatternBenefit benefit = 1)
+ LinearizeVectorBitCast(const TypeConverter &typeConverter,
+ MLIRContext *context, PatternBenefit benefit = 1)
: OpConversionPattern(typeConverter, context, benefit) {}
LogicalResult
matchAndRewrite(vector::BitCastOp castOp, OpAdaptor adaptor,
|
|
FYI @nbpatel Not sure if should just land PRs like this without waiting for a review (thoughts @banach-space ?) |
I’d land without review for obvious or trivial fixes - or when addressing a buildbot failure - and I think this PR falls into that category. Adding a short justification in the summary helps too (e.g., "This is straightforward and was requested in #NNNNNN, so landing without review.") Personally, I prefer getting an approval before merging, but reviewers are often busy, and reducing PR noise can sometimes be the more practical choice. That said, there’s an ongoing discussion on Discourse around post-commit review, which leans toward encouraging reviews for all patches - even smaller ones: |
Good advice, thanks! As for the thread -- I can't think of a real advantage/motivation for not first creating a PR. |
|
Can we merge this so I can rebase #137651 |
…llvm#138072) In llvm#136581 the bitwidth logic was supposed to be completely removed from the linearization patterns. But it was left in a few places. This PR removes the remainders (they were default valued constructor arguments that were unused).
…llvm#138072) In llvm#136581 the bitwidth logic was supposed to be completely removed from the linearization patterns. But it was left in a few places. This PR removes the remainders (they were default valued constructor arguments that were unused).
…llvm#138072) In llvm#136581 the bitwidth logic was supposed to be completely removed from the linearization patterns. But it was left in a few places. This PR removes the remainders (they were default valued constructor arguments that were unused).
…llvm#138072) In llvm#136581 the bitwidth logic was supposed to be completely removed from the linearization patterns. But it was left in a few places. This PR removes the remainders (they were default valued constructor arguments that were unused).
In #136581 the bitwidth logic was supposed to be completely removed from the linearization patterns. But it was left in a few places. This PR removes the remainders (they were default valued constructor arguments that were unused).