@@ -1057,15 +1057,17 @@ (define_insn ""
[(set_attr "type" "load")])
(define_expand "zero_extendqisi2"
- [(set (match_operand:SI 0 "mcore_arith_reg_operand" "")
- (zero_extend:SI (match_operand:QI 1 "general_operand" "")))]
+ [(parallel [(set (match_operand:SI 0 "mcore_arith_reg_operand" "")
+ (zero_extend:SI (match_operand:QI 1 "general_operand" "")))
+ (clobber (reg:CC 17))])]
""
"")
;; RBE: XXX: we don't recognize that the xtrb3 kills the CC register.
(define_insn ""
[(set (match_operand:SI 0 "mcore_arith_reg_operand" "=r,b,r")
- (zero_extend:SI (match_operand:QI 1 "general_operand" "0,r,m")))]
+ (zero_extend:SI (match_operand:QI 1 "general_operand" "0,r,m")))
+ (clobber (reg:CC 17))]
""
"@
zextb %0
@@ -1091,15 +1093,17 @@ (define_insn ""
[(set_attr "type" "load")])
(define_expand "zero_extendqihi2"
- [(set (match_operand:HI 0 "mcore_arith_reg_operand" "")
- (zero_extend:HI (match_operand:QI 1 "general_operand" "")))]
+ [(parallel [(set (match_operand:HI 0 "mcore_arith_reg_operand" "")
+ (zero_extend:HI (match_operand:QI 1 "general_operand" "")))
+ (clobber (reg:CC 17))])]
""
"")
;; RBE: XXX: we don't recognize that the xtrb3 kills the CC register.
(define_insn ""
[(set (match_operand:HI 0 "mcore_arith_reg_operand" "=r,b,r")
- (zero_extend:HI (match_operand:QI 1 "general_operand" "0,r,m")))]
+ (zero_extend:HI (match_operand:QI 1 "general_operand" "0,r,m")))
+ (clobber (reg:CC 17))]
""
"@
zextb %0
So the recent IRA change exposed a bug in the mcore backend. The mcore has a special instruction (xtrb3) which can zero extend a GPR into R1. It's useful because zextb requires a matching source/destination. Unfortunately xtrb3 modifies CC. The IRA changes twiddle register allocation such that we want to use xtrb3. Unfortunately CC is live at the point where we want to use xtrb3 and clobbering CC causes the test to fail. Exposing the clobber in the expander and insn seems like the best path forward. We could also drop the xtrb3 alternative, but that seems like it would hurt codegen more than exposing the clobber. The bitfield extraction patterns using xtrb look problematic as well, but I didn't try to fix those. This fixes the builtn-arith-overflow regressions and appears to fix 20010122-1.c as a side effect. Pushing to the trunk. Jeff commit 9fbbad9b6c6e7fa7eaf37552173f5b8b2958976b Author: Jeff Law <jlaw@ventanamicro.com> Date: Fri Jun 28 18:36:50 2024 -0600 [committed] Fix mcore-elf regression after recent IRA change So the recent IRA change exposed a bug in the mcore backend. The mcore has a special instruction (xtrb3) which can zero extend a GPR into R1. It's useful because zextb requires a matching source/destination. Unfortunately xtrb3 modifies CC. The IRA changes twiddle register allocation such that we want to use xtrb3. Unfortunately CC is live at the point where we want to use xtrb3 and clobbering CC causes the test to fail. Exposing the clobber in the expander and insn seems like the best path forward. We could also drop the xtrb3 alternative, but that seems like it would hurt codegen more than exposing the clobber. The bitfield extraction patterns using xtrb look problematic as well, but I didn't try to fix those. This fixes the builtn-arith-overflow regressions and appears to fix 20010122-1.c as a side effect. gcc/ * config/mcore/mcore.md (zero_extendqihi2): Clobber CC in expander and matching insn. (zero_extendqisi2): Likewise.