On Sun, Feb 9, 2025 at 11:31 PM Jakub Jelinek <ja...@redhat.com> wrote: > > On Sun, Feb 09, 2025 at 09:24:30AM +0100, Uros Bizjak wrote: > > "For commutative and comparison operators, a constant is always made > > the second operand." > > Isn't that just for commutative comparison operators (eq, ne, ordered, > unordered, ltgt, uneq)? Compare itself even isn't RTX_COMPARE at all, > it is RTX_BIN_ARITH, so similar to minus. > And I must say I can't find where simplify-rtx.cc or combine.cc would be > trying to canonicalize that order (note, it would need to change the related > uses of flags as well).
When combine combines some RTX with any operand of COMPARE RTX, it canonicalizes COMPARE RTX in simplify_compare_const: /* Try to simplify a comparison between OP0 and a constant OP1, where CODE is the comparison code that will be tested, into a (CODE OP0 const0_rtx) form. The result is a possibly different comparison code to use. *POP0 and *POP1 may be updated. */ This form won't match the new BT RTX. At the moment, there is no instruction using compare:CCC that could be combined with e.g. ZERO_EXTRACT RTX to form "*bt<mode>" insn, so the canonicalization rules do not matter, because BT is always expanded from splitters in a kind-of manual way. This is the reason that patch is OK, but without adding the new form to ix86_canonicalize_comparison, combine won't be able to match the new BT RTX in future. Please see ix86_canonicalize_comparison for a couple of examples on how to allow combine to match non-canonical compares. Uros.
