https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125387
--- Comment #2 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Jeff Law <[email protected]>: https://gcc.gnu.org/g:bed251d3acf34ecdb27eed40fbc4a672a299e1de commit r17-1341-gbed251d3acf34ecdb27eed40fbc4a672a299e1de Author: Raphael Zinsly <[email protected]> Date: Thu Jun 4 07:08:08 2026 -0600 [V2][PR target/125387][RISC-V] Properly cost mulh for RISC-V Bah. Sent the wrong version. The integer multiply cost in the tuning structure already has COSTS_N_INSNS applied, so no need to apply it again (which causes the costs to skyrocket and the code generation we want to see not happen). -- This is a patch Raphael wrote a few years back, but which never got upstreamed. I can vaguely recall evaluating the patch and concluding to drop it both internally and from the queue of things to upstream. But the details of how I reached that conclusion are lost. The core problem is we didn't recognize the fairly complex widening multiply RTL, so it got costed by recursion which is painful on its own. To add insult to injury the input operands are TI mode which, IIRC, also increased the cost of the mulh insn. The net was a totally bogus cost, it was totally off the charts which in turn discouraged using multiplies for division-by-constant operations as can be seen in the BZ. This patch from Raphael fixes recognition of the mulh RTL and uses the integer multiply cost out of the costing structure. This results in sensible costs for the multiply and using a multiply-by-reciprocal instead of division in more cases. It's been tested on riscv32-elf and riscv64-elf without regressions. I haven't bootstrapped it as I had my system disabled yesterday for "reasons". I'll obviously wait for the pre-commit verdict. PR target/125387 gcc/ * config/riscv/riscv.cc (riscv_rtx_costs): Recognize and properly cost mulh instructions. gcc/testsuite * gcc.target/riscv/pr125387.c: New test. Co-authored-by: Jeff Law <[email protected]>
