[PATCH] D94546: [RISCV] Optimize select_cc after fp compare expansion

[Craig Topper via Phabricator via llvm-commits]

craig.topper added inline comments.


================
Comment at: llvm/lib/Target/RISCV/RISCVISelLowering.cpp:1819-1820
+    // Transform
+    // (select_cc (xor X, 1), 0, setne, trueV, falseV) ->
+    // (select_cc X, 0, seteq, trueV, falseV) if we can prove X is 0/1.
+    // This can occur when legalizing some floating point comparisons.
----------------
jrtc27 wrote:
> Is there a reason not to generalise this to be any condition code and its negation?
Not all condition codes are supported on select_cc. See normaliseSetCC. I could handle ISD::SETEQ->ISD::SETNE as well. I'd have to think through the logic for other comparisons.


================
Comment at: llvm/lib/Target/RISCV/RISCVISelLowering.cpp:1826
+    if (N->getConstantOperandVal(2) == ISD::SETNE && isNullConstant(RHS) &&
+        LHS.getOpcode() == ISD::XOR && LHS.hasOneUse() &&
+        isOneConstant(LHS.getOperand(1)) &&
----------------
jrtc27 wrote:
> Hm, do we need it to have just one use? I could imagine it being better for instruction scheduling to be able to do:
> ```
> %0 = ...
> %1 = xor %0, 1
> %2 = select_cc %0, 0, seteq, trueV, falseV
> %3 = ... %1 ...
> ```
> even though it's not a code size win, though it does come at the expense of slightly increased register pressure.
True. It's also possible to have more than 1 select_cc with the same condition.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94546