I am trying to understand why sign extension removals are handled in multiple places in the RISC-V backend. Suppose the case of ADDW. First of all,RISCVInstrInfo.td contains its patters. In the same file, there’s a pattern for sign extensions removal.
Then, in RISCVISelLowring.cpp, there’s the member function doPeepholeSExtW that is responsible for 2 things: remove unnecessary sign extensions and combining sext.w on ADD into a single ADDW. Aren’t both of these cases already handled in the previous file?
Then, there’s RISCVSExtRemoval.cpp, a MachineFunctionPass which, in my understanding, runs only in RISC-V assembly. Why try to remove sign extensions when they have already been removed with code from the previous 2 files? Especially for this case, my guess is that it exists for handwritten RISC-V assembly where IR → RISC-V patterns have no effect?
Deferring the conversion from ADD from ADDW can permit other preferred instruction selection patterns to take precedence. ⚙ D107708 [RISCV] Remove sext_inreg+add/sub/mul/shl isel patterns. shows some tests that benefit from this approach and has the rationale in the summary.
Assembly doesn’t undergo instruction selection and optimisation. Again, you can read the rationale in the associated revision, ⚙ D116397 [RISCV] Add an MIR pass to replace redundant sext.w instructions with copies.. It provides a way to catch opportunities late in the pipeline, whether because earlier instruction patterns missed them, because other optimisations made them possible when they weren’t before or because spotting them requires cross basic-block knowledge; it’s important to bear in mind that SelectionDAG operates solely at the basic block level, whereas MIR passes get run after instruction selection has finished and thus has visibility of the entire function.