https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116398

--- Comment #29 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The trunk branch has been updated by Richard Sandiford <rsand...@gcc.gnu.org>:

https://gcc.gnu.org/g:4d7a634f6d41029811cdcbd5f7282b5b07890094

commit r15-9239-g4d7a634f6d41029811cdcbd5f7282b5b07890094
Author: Richard Sandiford <richard.sandif...@arm.com>
Date:   Mon Apr 7 08:03:47 2025 +0100

    combine: Allow 2->2 combinations, but with a tweak [PR116398]

    One of the problems in PR101523 was that, after each successful
    2->2 combination attempt, try_combine would restart combination
    attempts at i2 even if i2 hadn't changed.  This led to quadratic
    behaviour as the same failed combinations between i2 and i3 were
    tried repeatedly.

    The original patch for the PR dealt with that by disallowing 2->2
    combinations.  However, that led to various optimisation regressions,
    so there was interest in allowing the combinations again, at least
    until an alternative way of getting the same results is in place.

    This patch is a variant of Richi's in:

      https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523#c53

    but limited to when we're combining 2 instructions.

    This speeds up combine by 10x on the original PR101523 testcase
    and reduces combine's memory footprint by 100x.

    gcc/
            PR testsuite/116398
            * combine.cc (try_combine): Reallow 2->2 combinations.  Detect when
            only i3 has changed and restart from i3 in that case.

    gcc/testsuite/
            * gcc.target/aarch64/popcnt-le-1.c: Account for commutativity of
TST.
            * gcc.target/aarch64/popcnt-le-3.c: Likewise AND.
            * gcc.target/aarch64/pr100056.c: Revert previous patch.
            * gcc.target/aarch64/sve/pred-not-gen-1.c: Likewise.
            * gcc.target/aarch64/sve/pred-not-gen-4.c: Likewise.
            * gcc.target/aarch64/sve/var_stride_2.c: Likewise.
            * gcc.target/aarch64/sve/var_stride_4.c: Likewise.

    Co-authored-by: Richard Biener <rguent...@suse.de>

Reply via email to