[llvm] [RISCV] Use C.ADD when OR is not compressible due to register restriction (PR #156044)

[Sam Elliott via llvm-commits]

================
@@ -1178,7 +1178,21 @@ bool RISCVAsmPrinter::lowerToMCInst(const MachineInstr *MI, MCInst &OutMI) {
   if (lowerRISCVVMachineInstrToMCInst(MI, OutMI, STI))
     return false;
 
-  OutMI.setOpcode(MI->getOpcode());
+  unsigned Opcode = MI->getOpcode();
+  // If we have a disjoint OR which isn't compressible as an c.or, we can
+  // convert it to a c.add which doesn't have the gprc register restriction.
+  if (STI->hasStdExtZca() && Opcode == RISCV::OR &&
----------------
lenary wrote:

> Is your objection that I'm adding an optimization into something otherwise purely functional?

Broadly, yes. All the MIs with special handling in that function are Pseudos, not well-formed executable/encodable instructions. I don't think someone debugging codegen would expect that function to modify instructions in this way, but maybe it would be obvious with a `-print-after-all` or similar invocation.

> RISCVMakeCompressible is currently gated by MinSize. That's my entire objection.

Understood on the MinSize vs OptSize vs no-gating on MakeCompressible. We want to run that pass at OptSize as well as MinSize (we have an internal patch for this that should go up in the next day or so). A quick look at https://reviews.llvm.org/D92105 shows that there was some debate about Oz vs Os and you suggested the pass would be good even at O2. I'm not sure these decisions have been revisited since then with the community.

I'm about to be out for a week, so:
- I'm not going to block this patch.
- I'm in favour of revisiting when RISCVMakeCompressible runs.
- After that we can make a decision whether move this optimisation in there, or whether it's still better to be in this location.

I hope this is reasonable for a fix-forward approach, which should unblock any register allocation improvements you might want to do.



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