]> git.ipfire.org Git - thirdparty/gcc.git/commit
lra: Don't apply eliminations to allocated registers [PR116321]
authorRichard Sandiford <richard.sandiford@arm.com>
Tue, 27 Aug 2024 08:48:28 +0000 (09:48 +0100)
committerRichard Sandiford <richard.sandiford@arm.com>
Tue, 27 Aug 2024 08:48:28 +0000 (09:48 +0100)
commit9db997e5ac4a206b9428eb2447fcdc90e37725f4
tree2ad1523aa55d95bfe2a0a7e07d933c3c416e8bf9
parent8d6d6c864442a1cc987b3e6bcb1d903ceb975e4a
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.
gcc/lra-constraints.cc