SDValues, fixing the two bugs left in the regression suite.
The key for both of these was the use a single value type rather than
a VTList which caused an unintentionally single-result merge-value node.
Fix this by getting the appropriate VTList in place.
Doing this exposed that the comments in x86's code abouth how MUL_LOHI
operands are handle is wrong. The bug with the use of out-of-range
result numbers was hiding the bug about the order of operands here (as
best i can tell). There are more places where the code appears to get
this backwards still...
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213931
91177308-0d34-0410-b5e6-
96231b3b80d8
inline SDValue::SDValue(SDNode *node, unsigned resno)
: Node(node), ResNo(resno) {
-// This is currently disabled because it fires pretty widely, but I wanted to
-// commit it so others could help reproduce and aid in the cleanup. It will get
-// enabled ASAP.
-#if 0
assert((!Node || ResNo < Node->getNumValues()) &&
"Invalid result number for the given node!");
-#endif
assert(ResNo < -2U && "Cannot use result numbers reserved for DenseMaps.");
}
SDValue Denominator = Op.getOperand(2);
SDValue Src0 = Param->isAllOnesValue() ? Numerator : Denominator;
- return DAG.getNode(AMDGPUISD::DIV_SCALE, DL, VT,
- Src0, Denominator, Numerator);
+ return DAG.getNode(AMDGPUISD::DIV_SCALE, DL, Op->getVTList(), Src0,
+ Denominator, Numerator);
}
case Intrinsic::AMDGPU_div_fmas:
Highs = DAG.getNode(ISD::SUB, dl, VT, Highs, Fixup);
}
- // The low part of a MUL_LOHI is supposed to be the first value and the
- // high part the second value.
- return DAG.getNode(ISD::MERGE_VALUES, dl, Op.getValueType(), Lows, Highs);
+ // THe first result of MUL_LOHI is actually the high value, followed by the
+ // low value.
+ SDValue Ops[] = {Highs, Lows};
+ return DAG.getMergeValues(Ops, dl);
}
static SDValue LowerScalarImmediateShift(SDValue Op, SelectionDAG &DAG,