https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116326
--- Comment #4 from Richard Sandiford <rsandifo at gcc dot gnu.org> ---
(In reply to Georg-Johann Lay from comment #3)
> It was due to problems with multi-reg frame-pointer. (AFAIR, using a
> hard-frame-poiner besides frame-poiner didn't resolve the issues.)
>
> My problem now is that avr.h has:
>
> #define ELIMINABLE_REGS { \
> { ARG_POINTER_REGNUM, STACK_POINTER_REGNUM }, \
> { ARG_POINTER_REGNUM, FRAME_POINTER_REGNUM }, \
> { FRAME_POINTER_REGNUM, STACK_POINTER_REGNUM }, \
> { FRAME_POINTER_REGNUM + 1, STACK_POINTER_REGNUM + 1 } }
>
> but ira.cc uses that to initialize a static const array, hence there's no
> way to depend that on options I guess?
Yeah. And I don't think it's worth adding a way to make it depend on an
option, since it will only be a temporary state until LRA is fully supported.
Could you "just" remove the final entry locally while testing -mlra?
> One solution would be to skip upper parts of multi-part pointers in
> elimination. (And maybe other places: TARGET_HARD_REGNO_SCRATCH_OK and
> HARD_REGNO_RENAME_OK assume special handling for the high part of multi-reg
> FP, too).
In backend code, or in middle-end code?
But either way, I think we should start with the assumption that the entry
should be removed and make everything else work to that. Unfortunately that
probably excludes reload though, if the original problem that motivated the
entry was there.
