On Wed, Jan 29, 2025 at 04:44:55PM +0000, Richard Sandiford wrote:
> The PR showed two issues with pair-fusion. The first is that the pass
> treated stack pointer deallocations as ordinary register updates, and so
> might move them earlier than another stack access (through a different
> base register) that doesn't alias the pair candidate.
>
> The simplest fix for that seems to be to prevent the stack deallocation
> from being moved. This part might (or might not) be a latent source of
> wrong code and so worth backporting in some form. (The patch as-is
> won't work for GCC 14.)
>
> The second issue only started with r15-6551, which added a memory
> write to stack allocations and deallocations. We should use the
> existing tombstone mechanism to preserve the associated memory
> definition. (Deleting definitions immediately would have quadratic
> complexity in the worst case.)
>
> Tested on aarch64-linux-gnu. OK to install?
>
> Richard
>
>
> gcc/
> PR rtl-optimization/118429
> * pair-fusion.cc (latest_hazard_before): Add an extra parameter
> to say whether the instruction is a load or a store. If the
> instruction is not a load or store and has memory side effects,
> prevent it from being moved earlier.
> (pair_fusion::find_trailing_add): Update call accordingly.
> (pair_fusion_bb_info::fuse_pair): If the trailng addition had
> a memory side-effect, use a tombstone to preserve it.
>
> gcc/testsuite/
> PR rtl-optimization/118429
> * gcc.c-torture/compile/pr118429.c: New test.
Ok.
Jakub
