On 4/25/25 9:29 AM, Richard Sandiford wrote:
@@ -4274,6 +4286,18 @@ simplify_context::simplify_binary_operation_1 (rtx_code
code,
return simplify_gen_binary (LSHIFTRT, mode, XEXP (op0, 0), XEXP
(op0, 1));
}
+ /* Convert (and (subreg (not X) off) Y) into (and (not (subreg X off)) Y)
+ to expose opportunities to combine AND and NOT. */
+ if (GET_CODE (op0) == SUBREG
I think we should also check !paradoxical_subreg_p (op0). There are
two reasons:
(1) (and (subreg (something-narrower)) (const_int mask)) is a common
zero-extension idiom. Pushing the subreg down into the first
operand would prevent that.
(2) Applying the rule in the paradoxical case would compute the NOT
in a wider mode, which might be more expensive.
I'd gotten as far as concluding it was safe from a correctness
standpoint to not test for paradoxicals. But I hadn't even considered
the impact it could have on the zero extension idiom which seems fairly
important.
I'm not as worried about the size of the NOT. If NOT in a wider mode is
more expensive, then it probably should be reflected as such in rtx
costing for that port and the right things should just happen for the
most part.
But yes, I'm overall supportive of the patch and I think Richard's
comments are solid recommendations.
Jeff
