https://gcc.gnu.org/g:95f3eb053e366cf3302aa8ffeaa3770be016447b
commit r17-4997-g95f3eb053e366cf3302aa8ffeaa3770be016447b Author: Jeff Law <[email protected]> Date: Thu Oct 8 06:58:27 2026 -0600 [STORMY16] Steer aop towards IOR The more aggressive use of aop triggered a regression on the xstormy port: Tests that now fail, but worked before (1 tests): xstormy16-sim: gcc: gcc.target/xstormy16/swpn-4.c --save-temps -fno-inline-functions -L/home/jlaw/jenkins/workspace/xstormy16-elf/gcc/gcc/testsuite/gcc.target/xstormy16 scan-assembler-times swpn r2 18 I compared the before/after and it was painfully clear that the old code was more efficient than the new code. So an aop pattern to steer back towards IOR seems appropriate. I used two expanders because the QI/HI mode IOR patterns had different operand predicates that I wanted to match. gcc/ * config/stormy16/stormy16.md (aopqi3, aophi3): New expanders. Diff: --- gcc/config/stormy16/stormy16.md | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) diff --git a/gcc/config/stormy16/stormy16.md b/gcc/config/stormy16/stormy16.md index 89f3b59032c3..fce056bbe96a 100644 --- a/gcc/config/stormy16/stormy16.md +++ b/gcc/config/stormy16/stormy16.md @@ -1419,3 +1419,26 @@ (set (match_dup 0) (ior:HI (match_dup 3) (match_dup 2)))] "operands[3] = gen_reg_rtx (HImode);") + +(define_expand "aopqi3" + [(set (match_operand:QI 0 "xstormy16_below100_or_register") + (ior:QI (match_operand:QI 1 "xstormy16_below100_or_register") + (match_operand:QI 2 "nonmemory_operand")))] + "" + { + emit_insn (gen_iorqi3 (operands[0], operands[1], operands[2])); + DONE; + } +) + +(define_expand "aophi3" + [(set (match_operand:HI 0 "xstormy16_splittable_below100_or_register") + (ior:HI (match_operand:HI 1 "xstormy16_below100_or_register") + (match_operand:HI 2 "nonmemory_operand")))] + "" + { + emit_insn (gen_iorhi3 (operands[0], operands[1], operands[2])); + DONE; + } +) +
