https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116321
--- Comment #6 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:9db997e5ac4a206b9428eb2447fcdc90e37725f4 commit r15-3212-g9db997e5ac4a206b9428eb2447fcdc90e37725f4 Author: Richard Sandiford <richard.sandif...@arm.com> Date: Tue Aug 27 09:48:28 2024 +0100 lra: Don't apply eliminations to allocated registers [PR116321] The sequence of events in this PR is that: - the function has many addresses in which only a single hard base register is acceptable. Let's call the hard register H. - IRA allocates that register to one of the pseudo base registers. Let's call the pseudo register P. - Some of the other addresses that require H occur when P is still live. - LRA therefore has to spill P. - When it reallocates P, LRA chooses to use FRAME_POINTER_REGNUM, which has been eliminated to the stack pointer. (This is ok, since the frame register is free.) - Spilling P causes LRA to reprocess the instruction that uses P. - When reprocessing the address that has P as its base, LRA first applies the new allocation, to get FRAME_POINTER_REGNUM, and then applies the elimination, to get the stack pointer. The last step seems wrong: the elimination should only apply to pre-existing uses of FRAME_POINTER_REGNUM, not to uses that result from allocating pseudos. Applying both means that we get the wrong register number, and therefore the wrong class. The PR is about an existing testcase that fails with LRA on m86k. gcc/ PR middle-end/116321 * lra-constraints.cc (get_hard_regno): Only apply eliminations to existing hard registers. (get_reg_class): Likewise.
