[Mlir-commits] [mlir] [MLIR] Folding unpack and pack sequence in data layout propagation from padded domain (PR #138332)
Han-Chung Wang
llvmlistbot at llvm.org
Mon May 5 14:24:16 PDT 2025
================
@@ -298,20 +298,60 @@ getOrCreatePackedViewOfOperand(OpBuilder &b, Location loc, PackInfo packInfo,
return std::make_tuple(packedOperand, indexingMap);
}
+static bool isGenericOutsNotUsed(linalg::GenericOp genericOp) {
+ int numDpsOuts = genericOp.getNumDpsInits();
+ Block *block = genericOp.getBody();
+ int numBlockArgs = block->getNumArguments();
+ int initArgStartIndex = numBlockArgs - numDpsOuts;
+ for (int i = 0; i < numDpsOuts; ++i) {
+ int matchingInitArgIndex = initArgStartIndex + i;
+ return block->getArgument(matchingInitArgIndex).use_empty();
+ }
+ return true;
+}
+
/// Pack a genericOp and return it.
static GenericOp packGenericOp(RewriterBase &rewriter, GenericOp genericOp,
Value dest, AffineMap packedOutIndexingMap,
- const PackInfo &packInfo) {
+ const PackInfo &packInfo,
+ bool canUnpackPackFold) {
Location loc = genericOp.getLoc();
SmallVector<Value> inputOperands;
+ SmallVector<Value> inputOperandsFromUnpackedSource;
SmallVector<AffineMap> indexingMaps;
+
for (OpOperand *inputOperand : genericOp.getDpsInputOperands()) {
auto [packedOperand, packedIndexingMap] = getOrCreatePackedViewOfOperand(
rewriter, loc, packInfo, genericOp, inputOperand);
+
+ if (auto unpackOp = inputOperand->get().getDefiningOp<linalg::UnPackOp>()) {
+ inputOperandsFromUnpackedSource.push_back(unpackOp.getSource());
+ } else {
+ inputOperandsFromUnpackedSource.push_back(packedOperand);
+ }
+
----------------
hanhanW wrote:
style nit: I'd remove the blank lines in this area because they don't improve readability. LLVM does not have formal style documentation about vertical whitespace. (or I just didn't find it.) Generally, my rule is not using blank lines when you don't have to. This is what I learned from Google c++ style guide, and I think the idea applies to the case. They belong to the same paragraph, IMO. There are exceptions like a blank line before a comment line usually helps readability.
> This is more a principle than a rule: don't use blank lines when you don't have to. In particular, don't put more than one or two blank lines between functions, resist starting functions with a blank line, don't end functions with a blank line, and be sparing with your use of blank lines. A blank line within a block of code serves like a paragraph break in prose: visually separating two thoughts.
>
> The basic principle is: The more code that fits on one screen, the easier it is to follow and understand the control flow of the program. Use whitespace purposefully to provide separation in that flow.
https://google.github.io/styleguide/cppguide.html#Vertical_Whitespace
https://github.com/llvm/llvm-project/pull/138332
More information about the Mlir-commits
mailing list