The regression was reported during stage-1. A patch was provided during stage 1
and the discussions around combine stalled.
The regression for AArch64 needs to be fixed in GCC 13. The hit is too big just
to "take".
So we need a way forward, even if it's stage-4.
Thanks,
Tamar
________________________________
From: Segher Boessenkool <seg...@kernel.crashing.org>
Sent: Saturday, March 4, 2023 10:17 PM
To: Roger Sayle <ro...@nextmovesoftware.com>
Cc: 'GCC Patches' <gcc-patches@gcc.gnu.org>; Tamar Christina
<tamar.christ...@arm.com>; Richard Sandiford <richard.sandif...@arm.com>
Subject: Re: [PATCH] PR rtl-optimization/106594: Preserve zero_extend in
combine when cheap.
On Sat, Mar 04, 2023 at 06:32:15PM -0000, Roger Sayle wrote:
> This patch addresses PR rtl-optimization/106594, a P1 performance
> regression affecting aarch64.
>
> This patch has been tested on x86_64-pc-linux-gnu with make bootstrap
> and make -k check, both with and without --target_board=unix{-m32},
> with no new failures.
It should be tested for performance everywhere else, too.
It can very easily result in worse code on some targets. This kind of
thing really should be done in stage 1, not stage 4.
> PR rtl-optimization/106594
> * combine.cc (expand_compound_operation): Don't expand/transform
> ZERO_EXTEND or SIGN_EXTEND on targets where rtx_cost claims they are
> cheap.
That is not how combine works. If the old code is more expensive than
what combine comes up with., it *should* transform it. Magic cost
cutoffs are not okay anywhere in combine, either.
If expand_compound_operation and friends misbehave (not really an "if",
unfortunately), then please fix that, instead of randomly disabling
parts of combine?
Segher
