[PATCH] D97859: [LegalizeDAG] Implement promotion rules for SELECT_CC

Craig Topper via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Mar 3 14:03:28 PST 2021


craig.topper added inline comments.


================
Comment at: llvm/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp:4728
+    // Cast the operands.
+    Tmp1 = DAG.getNode(ExtOp, dl, NVT, Node->getOperand(0));
+    Tmp2 = DAG.getNode(ExtOp, dl, NVT, Node->getOperand(1));
----------------
LemonBoy wrote:
> craig.topper wrote:
> > LemonBoy wrote:
> > > craig.topper wrote:
> > > > I believe ISD::SELECT_CC can have integer operands for the compare and FP operands for the result and true/false value.
> > > I actually tried to do so but hit an assertion when the previous node is RAUW'd.
> > > The assert message is `"Cannot replace uses of with self"`, some brief testing showed it complains after the `SELECT_CC` is promoted for the second time.
> > Sorry, what exactly did you try to do?   My point was only that you can't assume the same extend opcode is valid for all operands or that all operands want to be promoted to NVT.
> Sorry, I misread your previous comment. I now get there are two possibly different types at play here.
> 
> Given the Promote rule kicks in according to the true/false type can we assume the comparison operands are already legalized? Should I try to expand those as well? And if so, is there a way to check if the comparison itself is legal?
My best idea is to promote them if they happen to have the same type and leave them alone otherwise. I don't think there's a way to check that the comparison is legal.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D97859/new/

https://reviews.llvm.org/D97859



More information about the llvm-commits mailing list