https://gcc.gnu.org/bugzilla/show_bug.cgi?id=127865
--- Comment #3 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:48ae7b09bc6b61bd383c45c25ddb36224a86c712 commit r17-5347-g48ae7b09bc6b61bd383c45c25ddb36224a86c712 Author: Jeff Law <[email protected]> Date: Mon Oct 19 10:01:18 2026 -0600 [PR target/127865][RISC-V] Refine selection of AOP for RISC-V So Anton's test showed a case where we'd have been better off steering towards PLUS for rv64 that had not occurred to me. In particular if we steer towards PLUS, then we can get sign extensions for free via addw/addiw; the sequence doesn't even have to end, they can appear in the middle of an instruction stream and allow us to eliminate a sign extension later as evidenced by Anton's test. So one more reason to steer towards PLUS. This has the potential to make identification of bseti harder. We'll have to monitor that and I wouldn't be surprised if final resolution of an AOP op really needs to wait until after combine is done. But that's definitely in the future work space. Bootstrapped and regression tested on the k3 and c920. K1 is in flight. Also tested on riscv32-elf and riscv64-elf. Pushing to the trunk. Assisted-By: LLM for patch review PR target/127865 gcc/ * config/riscv/riscv.md (aop<mode>3): Steer more operations towards PLUS for rv64. gcc/testsuite * gcc.target/riscv/pr127865.c: New test.
