[llvm] [SelectionDAG] Add support for the 3-way comparison intrinsics [US]CMP (PR #91871)

[via llvm-commits]

================
@@ -4426,6 +4511,56 @@ SDValue DAGTypeLegalizer::WidenVecRes_Binary(SDNode *N) {
                      {InOp1, InOp2, Mask, N->getOperand(3)}, N->getFlags());
 }
 
+SDValue DAGTypeLegalizer::WidenVecRes_CMP(SDNode *N) {
+  LLVMContext &Ctxt = *DAG.getContext();
+  SDLoc dl(N);
+
+  SDValue LHS = N->getOperand(0);
+  SDValue RHS = N->getOperand(1);
+  EVT OpVT = LHS.getValueType();
+  EVT TransformedOpVT = TLI.getTypeToTransformTo(Ctxt, OpVT);
+  if (TransformedOpVT.isVector() &&
+      TransformedOpVT.getVectorNumElements() > OpVT.getVectorNumElements()) {
+    LHS = GetWidenedVector(LHS);
+    RHS = GetWidenedVector(RHS);
+  }
+
+  EVT WidenResVT = TLI.getTypeToTransformTo(Ctxt, N->getValueType(0));
+  ElementCount WidenResEC = WidenResVT.getVectorElementCount();
+  EVT WidenResElementVT = WidenResVT.getVectorElementType();
+
+  // At this point we know that the type of operands should be legal,
----------------
Poseydon42 wrote:

Perhaps I've worded this comment a bit poorly. What I meant is that since (unless I'm massively misunderstanding something) the node that produces a value is legalized strictly before any nodes that use this value, the actual `SDValue`s of the operands that we retrieve a few lines above this comment are guaranteed to be correctly widened. I am not 100% confident that those types would be fully legal (i.e. the type wouldn't be something like <4 x i29>), but it shouldn't matter in this scenario I believe since `WidenVecRes_CMP` makes sure that the CMP node is retyped so that the return type and operand types match, so even if any further legalization is required after this point, the fact that the result and operand types are the same prevents us from running into legalization cycles. Hope this clarifies things a bit, and I will rewrite that comment a bit better shortly.

https://github.com/llvm/llvm-project/pull/91871