[Mlir-commits] [mlir] d3a31c4 - Remove case in rewritergen unmatched opdefgen side

Jacques Pienaar llvmlistbot at llvm.org
Mon Apr 6 16:04:09 PDT 2020


Author: Jacques Pienaar
Date: 2020-04-06T16:03:49-07:00
New Revision: d3a31c4db4e97ce30966f800238a0139134bffa7

URL: https://github.com/llvm/llvm-project/commit/d3a31c4db4e97ce30966f800238a0139134bffa7
DIFF: https://github.com/llvm/llvm-project/commit/d3a31c4db4e97ce30966f800238a0139134bffa7.diff

LOG: Remove case in rewritergen unmatched opdefgen side

The rewriter generates a call to build that is not handled by opdef generator
and so will fail to compile. Also if this is a root node being replaced
(depth 0) then using the more generic build method in the rewrite suffices.

Added: 
    

Modified: 
    mlir/tools/mlir-tblgen/RewriterGen.cpp

Removed: 
    


################################################################################
diff  --git a/mlir/tools/mlir-tblgen/RewriterGen.cpp b/mlir/tools/mlir-tblgen/RewriterGen.cpp
index 0cac412fecef..a4843167c83c 100644
--- a/mlir/tools/mlir-tblgen/RewriterGen.cpp
+++ b/mlir/tools/mlir-tblgen/RewriterGen.cpp
@@ -819,17 +819,9 @@ std::string PatternEmitter::handleOpCreation(DagNode tree, int resultIndex,
     return resultValue;
   }
 
-  // TODO: Remove once broadcastable has been updated. This query here is not
-  // really about broadcastable or not, it is about which build method to invoke
-  // and that requires knowledge of whether ODS generated a builder that need
-  // not take return types. That knowledge should be captured in one place
-  // rather than duplicated.
-  bool isResultsBroadcastableShape =
-      resultOp.getTrait("OpTrait::ResultsBroadcastableShape");
   bool usePartialResults = valuePackName != resultValue;
 
-  if (isResultsBroadcastableShape || usePartialResults || depth > 0 ||
-      resultIndex < 0) {
+  if (usePartialResults || depth > 0 || resultIndex < 0) {
     // For these cases (broadcastable ops, op results used both as auxiliary
     // values and replacement values, ops in nested patterns, auxiliary ops), we
     // still need to supply the result types when building the op. But because


        


More information about the Mlir-commits mailing list