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

[Craig Topper via Phabricator via llvm-commits]

craig.topper added inline comments.


================
Comment at: llvm/lib/Target/RISCV/RISCVISelLowering.cpp:9855
+  auto Next = next_nodbg(MI.getIterator(), BB->instr_end());
+  if (MI.getOpcode() != RISCV::Select_GPR_Using_CC_GPR && Next != BB->end() &&
+      Next->getOpcode() == MI.getOpcode() &&
----------------
liaolucy wrote:
> liaolucy wrote:
> > craig.topper wrote:
> > > liaolucy wrote:
> > > > craig.topper wrote:
> > > > > I think we also need to make sure the condition for the second select doesn't use the output from the first select.
> > > > I'm still confused. You mean, should I need to add:  Next->getOperand(4).getReg() != MI.getOperand(0).getReg() ? 
> > > > 
> > > > But, the assembly of the bug.ll file has not changed. 
> > > > 
> > > I was theorizing another possible bug. If either rs1 or rs2 of the second select is the result of the first select. Meaning one of the compare operands is also the false operand. It’s not safe to do the optimization. Is that already protected?
> >  If either rs1 or rs2 of the second select is the result of the first select. 
> > =======
> > This condition does not hold. 
> > 
> > eg: fpr32 = Select_FPR32_Using_CC_GPR killed %13:gpr, %24:gpr, 1, %19:fpr32, killed %30:fpr32
> > 
> > rs1 and rs2 are gpr,  but dst is fpr.
>  If either rs1 or rs2 of the second select is the result of the first select. 
> 
> This condition does not hold. 
> 
> eg: fpr32 = Select_FPR32_Using_CC_GPR killed %13:gpr, %24:gpr, 1, %19:fpr32, killed %30:fpr32
> 
> rs1 and rs2 are gpr,  but dst is fpr, 
You're right. I forgot this was FP only.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127871