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