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.
Pushed to the trunk.
jeff
gcc/
* config/stormy16/stormy16.md (aopqi3, aophi3): New expanders.
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 @@ (define_insn_and_split "*swpn_zext_ior"
(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;
+ }
+)
+
