https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124439
Robin Dapp <rdapp at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |stefansf at gcc dot gnu.org,
| |vmakarov at gcc dot gnu.org
--- Comment #5 from Robin Dapp <rdapp at gcc dot gnu.org> ---
Another possibility to fix PR124041 (and sidesteps the issue in this PR) is
diff --git a/gcc/lra-eliminations.cc b/gcc/lra-eliminations.cc
index 8e68cb70dcf..c4b6318ef7e 100644
--- a/gcc/lra-eliminations.cc
+++ b/gcc/lra-eliminations.cc
@@ -662,6 +662,8 @@ lra_eliminate_regs_1 (rtx_insn *insn, rtx x, machine_mode
mem_mode,
be an invalid one for outside of a debug insn. */
if (DEBUG_INSN_P (insn) && !nx)
nx = gen_rtx_raw_SUBREG (GET_MODE (x), new_rtx, SUBREG_BYTE
(x));
+ else if (!nx)
+ nx = move_plus_up (x);
gcc_assert (nx);
return nx;
}
I bootstrapped and regtested that on x86, power10, aarch64.
But this seems pretty ad-hoc. As my knowledge of lra is limited, I'd like to
bring Vlad into the discussion. From what I gathered today, PR124041's fix is
not ideal because we could just leave the eliminable frame pointer in place and
expect it to be eliminated (or rather make sure it will be).
Is the move_plus_up somehow reasonable? As far as I can tell eliminating will
only result in base + offset here, but...
