https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116374

--- Comment #7 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Michael Matz <m...@gcc.gnu.org>:

https://gcc.gnu.org/g:542773888190ef67dca194f4861abab104fa9b5b

commit r15-3220-g542773888190ef67dca194f4861abab104fa9b5b
Author: Michael Matz <m...@suse.de>
Date:   Thu Aug 22 17:09:11 2024 +0200

    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.

Reply via email to