[PATCH] D127871: [RISCV] Optimize 2x SELECT for floating-point types

[Liao Chunyu via Phabricator via llvm-commits]

liaolucy added inline comments.


================
Comment at: llvm/lib/Target/RISCV/RISCVISelLowering.cpp:9857
+      Next->getOpcode() == MI.getOpcode() &&
+      Next->getOperand(2).getReg() == MI.getOperand(2).getReg() &&
+      Next->getOperand(5).getReg() == MI.getOperand(0).getReg() &&
----------------
craig.topper wrote:
> I don't understand the new check. Why was it wrong to optimize 1.1 and 2.1 in the failed case?
Yesterday, I saw that x86 has  this check.

```

  // CMOV ((CMOV F, T, cc1), T, cc2) is checked here and handled by a separate
  // function - EmitLoweredCascadedSelect

  // This checks for case 2, but only do this if we didn't already find
  // case 1, as indicated by LastCMOV == MI.
  if (LastCMOV == &MI && NextMIIt != ThisMBB->end() &&
      NextMIIt->getOpcode() == MI.getOpcode() &&
      NextMIIt->getOperand(2).getReg() == MI.getOperand(2).getReg() &&
      NextMIIt->getOperand(1).getReg() == MI.getOperand(0).getReg() &&
      NextMIIt->getOperand(1).isKill()) {
    return EmitLoweredCascadedSelect(MI, *NextMIIt, ThisMBB);
  }

```

Try to understand：
 1.1 %29:fpr32 = Select_FPR32_Using_CC_GPR killed %7:gpr, %27:gpr, 4, %3:fpr32, killed %25:fpr3
 2.1 %30:fpr32 = Select_FPR32_Using_CC_GPR killed %18:gpr, %24:gpr, 1, %16:fpr32, killed %29:fpr32
 
%7 (a), %27 (b)
%18 (c), %24 (d) 
Eg: 
```
   a=b , c=d,
    a=b , c!=d
    a!=b, c=d,
    a!=b, c!=d
```

b=d:
```
%7 (a), %27 (b), 
%18 (c), %24 (b) 
a=b,  c=b     a=b=c
a=b,  c!=b 
                a!= c (optimize)   
a!=b, c=b
a!=b, c!=b   a!=b!=c
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127871