https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116398
--- Comment #31 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:107a1b2126ceb42a79edbc388863c868bd4fbc2e commit r15-9241-g107a1b2126ceb42a79edbc388863c868bd4fbc2e Author: Richard Sandiford <richard.sandif...@arm.com> Date: Mon Apr 7 08:03:48 2025 +0100 combine: Optimise distribute_links search [PR116398] Another problem in PR101523 was that, after each successful 2->2 combination attempt, distribute_links would search further and further for the next combinable use of the i2 destination. Each search would start at i2 itself, making the search quadratic in the worst case. In a 2->2 combination, if i2 is unchanged, the search can start at i3 instead of i2. The same thing applies to i2 when distributing i2's links, since the only changes to earlier instructions are the deletion of i0 and i1. This change, combined with the previous split_i2i3 patch, gives a 34.6% speedup in combine for the testcase in PR101523. Combine goes from being 41% to 34% of compile time. gcc/ PR testsuite/116398 * combine.cc (distribute_links): Take an optional start point. (try_combine): If only i3 has changed, only distribute i3's links, not i2's. Start the search for the new use from i3 rather than from the definition instruction. Likewise start the search for the new use from i2 when distributing i2's links.
