On 5/7/2026 1:14 PM, Richard Sandiford wrote:
> One quirk of the commutative operand precedence rules is that:
>
> - PLUS and MINUS have precedence 4
> - other binary arithmetic operators have precedence 2
> - NOT and NEG have precedence 1
> - (binary) comparison operators have precedence 0
>
> This means that the arithmetic inverse operator (NEG) has a lower
> precedence than the binary arithmetic operators, but the logical
> inverse operator (NOT) has a higher precedence than binary comparisons
> that produce a logical result. In other words, we have:
>
> some binary > some unary > some other binary
>
> This patch shuffles the precedence values so that all binary operators
> have precedence over all unary operators. It means that existing
> aarch64.md patterns such as:
>
> (define_insn "*add<mode>3_carryinC_zero"
> [(set (reg:CC_ADC CC_REGNUM)
> (compare:CC_ADC
> (plus:<DWI>
> (match_operand:<DWI> 2 "aarch64_carry_operation" "")
> (zero_extend:<DWI> (match_operand:GPI 1 "register_operand" "r")))
> (match_operand 4 "const_scalar_int_operand" "")))
> (set (match_operand:GPI 0 "register_operand" "=r")
> (plus:GPI (match_operand:GPI 3 "aarch64_carry_operation" "")
> (match_dup 1)))]
>
> are now canonical.
>
> Tested on aarch64-linux-gnu, powerpc64le-linux-gnu & x86_64-linux-gnu.
> OK to install?
>
> Richard
>
>
>
> gcc/
> * rtlanal.cc (commutative_operand_precedence): Bump the precedence
> of non-commutative binary arithmetic to 3. Give comparisons a
> precedence of 2.
OK. Between this and the combiner patch I kind of expect to see scan
test fallout somewhere. If I see any, I'll fix, file a bug or pass
along depending on time, complexity, etc.
jeff
