]> git.ipfire.org Git - thirdparty/gcc.git/commit
LRA: Don't use 0 as initialization for sp_offset
authorMichael Matz <matz@suse.de>
Thu, 22 Aug 2024 15:09:11 +0000 (17:09 +0200)
committerMichael Matz <matz@suse.de>
Tue, 27 Aug 2024 13:31:28 +0000 (15:31 +0200)
commit542773888190ef67dca194f4861abab104fa9b5b
tree5f920f3f68783db9fdf27e403a19516f60bd276b
parent359209bdc7245f8768b5044acded8509545e4990
LRA: Don't use 0 as initialization for sp_offset

this is part of making m68k work with LRA.  See PR116374.
m68k has the property that sometimes the elimation offset
between %sp and %argptr is zero.  During setting up elimination
infrastructure it's changes between sp_offset and previous_offset
that feed into insns_with_changed_offsets that ultimately will
setup looking at the instructions so marked.

But the initial values for sp_offset and previous_offset are
also zero.  So if the targets INITIAL_ELIMINATION_OFFSET (called
in update_reg_eliminate) is zero then nothing changes, the
instructions in question don't get into the list to consider and
the sp_offset tracking goes wrong.

Solve this by initializing those member with -1 instead of zero.
An initial offset of that value seems very unlikely, as it's
in word-sized increments.  This then also reveals a problem in
eliminate_regs_in_insn where it always uses sp_offset-previous_offset
as offset adjustment, even in the first_p pass.  That was harmless
when previous_offset was uninitialized as zero.  But all the other
code uses a different idiom of checking for first_p (or rather
update_p which is !replace_p&&!first_p), and using sp_offset directly.
So use that as well in eliminate_regs_in_insn.

PR target/116374
* lra-eliminations.cc (init_elim_table): Use -1 as initializer.
(update_reg_eliminate): Accept -1 as not-yet-used marker.
(eliminate_regs_in_insn): Use previous_sp_offset only when
not first_p.
gcc/lra-eliminations.cc