https://gcc.gnu.org/bugzilla/show_bug.cgi?id=127813
--- Comment #4 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:cebcce44cccc6829dd4854556c60cc6d2f59b28c commit r17-5103-gcebcce44cccc6829dd4854556c60cc6d2f59b28c Author: Jeff Law <[email protected]> Date: Mon Oct 12 20:51:11 2026 -0600 [RISC-V][PR 127813] Add more czero patterns/splitters for RISC-V So the first new pattern here is very straightforward. It's essentially the same pattern the VRULL guys did initially and I suggested they move towards the if-then-else form. This bug clearly shows that pattern useful. The two other patterns are more interesting. We'd really like to match the (and (neg (reg1)) (reg2)) when reg1 has a 0/1 value as a czero, similarly for the inverse which uses (plus (reg1) (const_int -1)). My first implementation checked nonzero_bits and matched that form directly generating the czero. Review via an LLM flagged that problem. For this testcase (and I think reasonably generally) we'll often see these wrapped by an IOR as part of a more general conditional move sequence constructed from logicals with the IOR doing final selection. So that's a 3->2 split that we can recognize in combine (using nonzero_bits), then immediately rewrite into a form that doesn't require that test. It's not ideal, but should be enough to capture the most common cases. Tested on riscv32-elf and riscv64-elf and bootstrapped and regression tested on the k3. c920 is being flaky so that'll have to spin overnight. k1 is queued and will pick this up on its next run which starts in an hour or two. Anyway, pushing this to the trunk. I'll keep the BZ open as Andrea wants to tackle some stuff up in match.pd in a generic way. PR tree-optimization/127813 gcc/ * config/riscv/zicond.md: Add new define_insn for czero expressed via logical ops. Add define_splits when related patterns are used by an IOR to select across two values. gcc/testsuite * gcc.target/riscv/pr127813.c: New test.
