Fix incorrect result type inference for nested tuples & remove hacky const case.
authorJacques Pienaar <jpienaar@google.com>
Sat, 25 May 2019 02:31:09 +0000 (19:31 -0700)
committerMehdi Amini <joker.eph@gmail.com>
Sun, 2 Jun 2019 03:02:33 +0000 (20:02 -0700)
    Builders can be further refined but wanted to address bug where the result type was used beyond the first depth.

--

PiperOrigin-RevId: 249936004

mlir/tools/mlir-tblgen/RewriterGen.cpp

index b00be1c..c29cf54 100644 (file)
@@ -674,20 +674,16 @@ std::string PatternEmitter::emitOpCreate(DagNode tree, int resultIndex,
 
   // Then we build the new op corresponding to this DAG node.
 
-  // TODO: this is a hack to support various constant ops. We are assuming
-  // all of them have no operands and one attribute here. Figure out a better
-  // way to do this.
-  bool isConstOp =
-      resultOp.getNumOperands() == 0 && resultOp.getNumNativeAttributes() == 1;
-
   bool isSameValueType = resultOp.hasTrait("SameOperandsAndResultType");
   bool isBroadcastable = resultOp.hasTrait("BroadcastableTwoOperandsOneResult");
   bool useFirstAttr = resultOp.hasTrait("FirstAttrDerivedResultType");
 
-  if (isConstOp || isSameValueType || isBroadcastable || useFirstAttr) {
+  if (isSameValueType || isBroadcastable || useFirstAttr || depth > 0) {
     os.indent(4) << formatv("auto {0} = rewriter.create<{1}>(loc", resultValue,
                             resultOp.getQualCppClassName());
   } else {
+    // If depth == 0 we can use the equivalence of the source and target root
+    // ops in the pattern to determine the return type.
     std::string resultType = formatv("op->getResult({0})", resultIndex).str();
 
     os.indent(4) << formatv(