diff options
author | Richard Sandiford <richard.sandiford@arm.com> | 2024-08-27 09:48:28 +0100 |
---|---|---|
committer | Richard Sandiford <richard.sandiford@arm.com> | 2024-08-27 09:48:28 +0100 |
commit | 9db997e5ac4a206b9428eb2447fcdc90e37725f4 (patch) | |
tree | 2ad1523aa55d95bfe2a0a7e07d933c3c416e8bf9 /libjava/org/w3c/dom | |
parent | 8d6d6c864442a1cc987b3e6bcb1d903ceb975e4a (diff) | |
download | gcc-9db997e5ac4a206b9428eb2447fcdc90e37725f4.zip gcc-9db997e5ac4a206b9428eb2447fcdc90e37725f4.tar.gz gcc-9db997e5ac4a206b9428eb2447fcdc90e37725f4.tar.bz2 |
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.
Diffstat (limited to 'libjava/org/w3c/dom')
0 files changed, 0 insertions, 0 deletions