[PATCH] D72022: [mlir][Linalg] Extend generic ops to allow tensors

Nicolas Vasilache via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Jan 2 14:39:15 PST 2020


nicolasvasilache marked 8 inline comments as done.
nicolasvasilache added a comment.
Herald added a subscriber: lucyrfox.

@yangjunpro addressed in https://reviews.llvm.org/D72112 thanks!



================
Comment at: mlir/include/mlir/Dialect/Linalg/IR/LinalgTraits.h:113
+           llvm::all_of(getInputsAndOutputs(),
+                        [](Value v) { return v.getType().isa<MemRefType>(); });
+  }
----------------
yangjunpro wrote:
> "Value v",  might change to pass by reference for better performance? Although it might be a little bit marginal here. 
Value is a POD, taking a reference would actually add a level of indirection and could be detrimental to perf.


================
Comment at: mlir/include/mlir/Dialect/Linalg/Transforms/LinalgTransforms.h:83
+LogicalResult vectorizeGenericLinalgOpPrecondition(Operation *op);
+SmallVector<Value, 0> vectorizeGenericLinalgOp(PatternRewriter &rewriter,
+                                               Operation *op);
----------------
yangjunpro wrote:
> Can't we directly write the return type as SmallVector<Value> ? "0" looks peculiar here. 
SmallVector really wants 2 template args.


================
Comment at: mlir/lib/Dialect/Linalg/IR/LinalgOps.cpp:302
+             << index << " must be " << outOpTy << ", but got " << resTy;
+    ++index;
+  }
----------------
yangjunpro wrote:
> If we already have the index, why do we bother to use the zip()?
> I think by directly use op.getResultTypes()[index], outputTensorTypes[index] is enough. 
`getResultTypes` is an iterator range and does not work with random access.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D72022/new/

https://reviews.llvm.org/D72022





More information about the llvm-commits mailing list