Hi,
Since I'm an active RX user myself, I'm interested in this as well.
I've briefly looked through it, some comments see below.
On Mon, 2026-03-16 at 18:18 +0900, Yoshinori Sato wrote:
>
> diff --git a/gcc/config/rx/rx.h b/gcc/config/rx/rx.h
> index 8c95ad9477f..9a655d0b60d 100644
> --- a/gcc/config/rx/rx.h
> +++ b/gcc/config/rx/rx.h
> @@ -160,7 +160,6 @@
> #define POINTERS_EXTEND_UNSIGNED 1
> #define FUNCTION_MODE QImode
> #define CASE_VECTOR_MODE Pmode
> -#define WORD_REGISTER_OPERATIONS 1
> #define HAS_LONG_COND_BRANCH 0
> #define HAS_LONG_UNCOND_BRANCH 0
It looks strange to undefine WORD_REGISTER_OPERATIONS here.
>From what I know, all RX operations are done on the full 32-bit registers.
Why was this done?
> +
> +(define_insn "movdi_internal"
> + [(set (match_operand:DI 0 "rx_double_dest_operand" "=r,r,m")
> + (match_operand:DI 1 "rx_double_src_operand" "ri,m,r"))]
> + ""
> + "#"
> + [(set_attr "length" "8")]
> +)
> +
> +(define_split
> + [(set (match_operand:DI 0 "nonimmediate_operand" "")
> + (match_operand:DI 1 "general_operand" ""))]
> + "reload_completed"
> + [(const_int 0)]
> + {
> + rx_split_double_move (operands, DImode);
> + DONE;
> + }
> +)
It looks like these two can be written as "define_insn_and_split".
Some other cases as well.
>
> -(define_insn "rotlsi3"
> +(define_expand "rotlsi3"
> + [(set (match_operand:SI 0 "register_operand" "")
> + (rotate:SI (match_operand:SI 1 "register_operand" "")
> + (match_operand:SI 2 "rx_shift_operand" "")))
> + (clobber (reg:CC CC_REG))]
> + ""
> + {
> + }
> +)
> +
> +(define_insn "*rotlsi3"
> [(set (match_operand:SI 0 "register_operand" "=r")
> (rotate:SI (match_operand:SI 1 "register_operand" "0")
> - (match_operand:SI 2 "rx_shift_operand" "rn")))
> - (clobber (reg:CC CC_REG))]
> + (match_operand:SI 2 "rx_shift_operand" "rn")))]
> ""
> "rotl\t%2, %0"
> [(set_attr "length" "3")]
> @@ -1477,11 +1430,20 @@
> [(set_attr "length" "3")]
> )
>
Why is it necessary to hide the CC clobbers from rotate and shift patterns?
I would expect this to be a potential source for silent wrong-code bugs in
the future, as it allows wrong insn reordering. I guess that's also the
reason why you cut out the "addsi3_flags", "adddi3", "subsi3_flags" and
"subdi3" patterns. This will result in worse code generated for 64-bit
arithmetic.
Best regards,
Oleg Endo
