https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104005
--- Comment #5 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Richard Sandiford <rsand...@gcc.gnu.org>: https://gcc.gnu.org/g:38ec23fafb167ddfe840d7bb22b3e943d8a7d29e commit r12-6669-g38ec23fafb167ddfe840d7bb22b3e943d8a7d29e Author: Richard Sandiford <richard.sandif...@arm.com> Date: Tue Jan 18 12:20:00 2022 +0000 aarch64: Fix overly optimistic LDP/STP matching [PR104005] In g:526e1639aa76b0a8496b0dc3a3ff2c450229544e I'd added support for finding more consecutive MEMs. However, the check was too eager, in that it matched MEM_REFs with the same base address even if that base address was an arbitrary SSA name. This can give wrong results if a MEM_REF from one loop iteration is compared with a MEM_REF from another (e.g. after rtl unrolling). In principle, we could still accept MEM_REFs based on the same incoming SSA name, but there seems to be no out-of-the-box API for doing that. Adding a new one at this stage in GCC 12 doesn't feel like a good risk/reward trade-off. This patch therefore restricts the MEM_EXPR comparison to base decls only, excluding all MEM_REFs. It means we lose all the new STPs in the PR testcase but keep the ones in the original stp_1.c testcase. gcc/ PR target/104005 * config/aarch64/aarch64.cc (aarch64_check_consecutive_mems): When using MEM_EXPR, require the base to be a decl. gcc/testsuite/ PR target/104005 * gcc.target/aarch64/pr104005.c: New test.
