[llvm] [RISCV][TII] Add and use new hook to optimize/canonicalize instructions after MachineCopyPropagation (PR #137973)
Alex Bradbury via llvm-commits
llvm-commits at lists.llvm.org
Wed Apr 30 23:01:56 PDT 2025
================
@@ -510,6 +510,16 @@ class TargetInstrInfo : public MCInstrInfo {
return false;
}
+ /// If possible, converts the instruction to a more 'optimized'/canonical
+ /// form. Returns true if the instruction was modified.
+ ///
+ /// This function is only called after register allocation. The MI will be
+ /// modified in place. This is called by passes such as
+ /// MachineCopyPropagation, where their mutation of the MI operands may
+ /// expose opportunities to convert the instruction to a simpler form (e.g.
+ /// a load of 0).
+ virtual bool optimizeInstruction(MachineInstr &MI) const { return false; }
----------------
asb wrote:
Craig's comment captures well the reason why I looked to do this in MCP. it seems like a transformation that's generally useful to other targets, and by adding and using a TII hook it's easy to reuse if we find any other target-specific or generic passes that might benefit (though as I say in the summary, all of the instances of these instructions I can find come from MCP). It could be done in another pass, but it felt like a simple change to have MCP "check its own work" might be cleaner than having yet another pass.
This specific change doesn't induce additional copy propagation, but looking at the generated diffs there are cases where you would expect copy propagation should be able to run again. I nod to this in the description above, but as this change alone is an improvement on before I leave that to a followup.
e.g. this snippet from parest:
```diff
@@ -2753,11 +2753,11 @@
bnez s11, .LBB0_353
.LBB0_357: # in Loop: Header=BB0_310 Depth=1
li a2, 0
- srliw a5, zero, 31
- slli a3, zero, 33
+ li a5, 0
+ li a3, 0
slli a5, a5, 15
srli a3, a3, 56
- and a4, zero, a1
+ li a4, 0
bgeu s8, a3, .LBB0_354
```
The slli/srli should be removable (canonicalised to loadimm of 0, and then redundant with the previous `li`). I haven't yet stepped through to see if this is a matter of doing another iteration in MCP or if there's some other barrier that prevents current MCP from handling the case.
https://github.com/llvm/llvm-project/pull/137973
More information about the llvm-commits
mailing list