On 9/30/26 12:53 AM, Dominic P wrote:
After three uses find_flags_uses_in_insn gives up and marks the uses
of a compare as unknown, so try_eliminate_compare keeps the original
CC mode and fails when the arithmetic only sets a narrower one, as
ANDS, ADDS and SUBS do on Arm and AArch64.  Four conditional moves or
csels fed by one "and; cmp #0" keep the compare.  Record the uses in
an auto_vec with inline room for three, so the common case still
needs no heap allocation.

Arm -O2 Linux .text: bcmrpi_defconfig -68 B (13 functions shrink, none
grow), bcm2709_defconfig -44 B.  No gcc.c-torture asm change on x86_64
or AArch64.

Bootstrapped and regression tested on x86_64-pc-linux-gnu; regression
tested on arm-none-eabi and aarch64-linux-gnu.

Assisted-by: Claude Opus 5 (Anthropic)

gcc/ChangeLog:

        * compare-elim.cc (MAX_CMP_USE): Remove.
        (struct comparison): Make uses an auto_vec.  Remove n_uses.
        (find_flags_uses_in_insn): Do not limit the number of uses.
        (maybe_select_cc_mode): Use uses.length ().
        (find_comparison_dom_walker::before_dom_children): Allocate
        comparisons with new.
        (execute_compare_elim_after_reload): Free them with delete in a
        range-based for, clearing each slot.

gcc/testsuite/ChangeLog:

        * gcc.target/aarch64/cmpelim_mult_uses_2.c: New test.
        * gcc.target/arm/cmpelim_mult_uses_1.c: New test.

Signed-off-by: Dominic P <[email protected]>
---
Changes in v3, from Andrea Pinski's review:
- The cleanup loop is now your range-based for with cmp = nullptr.
   The order matters, so I kept it rather than using pop: a later
   compare's setter can be an insn that uses an earlier compare's
   flags, which the earlier elimination may rewrite.  gcc.c-torture
   has one such pair on Arm; its asm is the same in either order.

x86_64 bootstrap and regression test redone; the Arm and AArch64
runs are v1's, as v3 generates identical gcc.c-torture asm.

OK for trunk?
OK
Jeff

Reply via email to