https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118429
--- Comment #13 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:a0a202d07339ff55793029b5bde152c38b90aaf5 commit r15-7277-ga0a202d07339ff55793029b5bde152c38b90aaf5 Author: Richard Sandiford <richard.sandif...@arm.com> Date: Wed Jan 29 17:44:53 2025 +0000 pair-fusion: A couple of fixes for sp updates [PR118429] 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.) 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.
