[LLVMbugs] [Bug 21539] New: TableGen errors if operand with suboperands used without repeating type in output pattern

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=21539

            Bug ID: 21539
           Summary: TableGen errors if operand with suboperands used
                    without repeating type in output pattern
           Product: tools
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: TableGen
          Assignee: unassignedbugs at nondot.org
          Reporter: Matthew.Arsenault at amd.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

If you attempt to use a custom Operand type with suboperands, and don't repeat
the type in the output pattern, there is an error from operand number mismatch.
For any other operand type, just specifying the name of the operand in the
result is enough.

e.g.

def MEMOP  : Operand<iPTR> {
  let MIOperandInfo = (ops PtrRC:$base, PtrRC:$reg, PtrRC:$offset);
  let PrintMethod = "printAddrMode3Op";
}

// OK, MEMOP explicitly mentioned in output pattern
class LDPat<Instruction inst, SDPatternOperator ldnode, ValueType vt> : Pat <
  (vt (ldnode (LoadAddr MEMOP:$address))),
  (inst MEMOP:$address) 
>;

// Errors, the complex operand only counts towards one operand of the output
instruction and errors when it should count as 3
class LDPat<Instruction inst, SDPatternOperator ldnode, ValueType vt> : Pat <
  (vt (ldnode (LoadAddr MEMOP:$address))),
  (inst $address)
>;





The problem is in CodeGenDAGPatterns.cpp:

          if (Child->getNumMIResults(CDP) < NumArgs) {
            // Match first sub-operand against the child we already have.
            Record *SubRec = cast<DefInit>(MIOpInfo->getArg(0))->getDef();
            MadeChange |=
              Child->UpdateNodeTypeFromInst(ChildResNo, SubRec, TP);

            // And the remaining sub-operands against subsequent children.
            for (unsigned Arg = 1; Arg < NumArgs; ++Arg) {
              if (ChildNo >= getNumChildren()) {
                emitTooFewOperandsError(TP, getOperator()->getName(),
                                        getNumChildren());
                return false;
              }
              Child = getChild(ChildNo++);

              SubRec = cast<DefInit>(MIOpInfo->getArg(Arg))->getDef();
              MadeChange |=
                Child->UpdateNodeTypeFromInst(ChildResNo, SubRec, TP);
            }
            continue;
          }

In the working case with the explicitly specified Operand type,
Child->getNumMIResults(CDP)
returns the correct 3 from the isLeaf() / dyn_cast<DefInit>() path. In the
broken case, this only returns 1 where the leaf is an UnsetInit. I'm not really
sure what this is attempting to do in the case where
Child->getNumMIResults(CDP) < NumArgs). Is it trying to allow using multiple
operands that together make up the components of a single complex operand?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20141112/d0709654/attachment.html>