https://gcc.gnu.org/g:601e53517fb1d322b558839d406f2ea0d6fbab09
commit r17-5030-g601e53517fb1d322b558839d406f2ea0d6fbab09 Author: Jeff Law <[email protected]> Date: Fri Oct 9 10:38:16 2026 -0600 [H8] Steer H8 towards IOR rather than PLUS most of the time So the any-or-plus changes tripped code quality regressions for the H8 port. H8 doesn't have shift-add, but does have some bit manipulation capabilities and IOR is cheaper than XOR. So generally steering towards IOR seems appropriate. However, for SImode, the two register form of ADD encodes smaller and is faster than IOR. So for that relatively narrow case, steering towards PLUS is better. So this introduces the aop expander that generally steers to IOR, but in that limited case will steer towards PLUS. That fixes the testsuite regressions. gcc/ * config/h8300/logical.md (aop<mode>3): New expander. Diff: --- gcc/config/h8300/logical.md | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/gcc/config/h8300/logical.md b/gcc/config/h8300/logical.md index 9550943fbcbb..140380f3434c 100644 --- a/gcc/config/h8300/logical.md +++ b/gcc/config/h8300/logical.md @@ -349,3 +349,20 @@ (parallel [(set (zero_extract:SI (match_dup 0) (const_int 8) (const_int 8)) (lshiftrt:SI (match_dup 1) (const_int 8))) (clobber (reg:CC CC_REG))])]) + +;; The two register form for PLUS is smaller and faster than the IOR or +;; XOR forms for SImode +(define_expand "aop<mode>3" + [(set (match_operand:QHSI 0 "register_operand") + (ior:QHSI (match_operand:QHSI 1 "register_operand") + (match_operand:QHSI 2 "h8300_src_operand")))] + "" + { + if (REG_P (operands[2]) && <MODE>mode == SImode) + emit_insn (gen_add<mode>3 (operands[0], operands[1], operands[2])); + else + emit_insn (gen_ior<mode>3 (operands[0], operands[1], operands[2])); + DONE; + } +) +
