https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116326
--- Comment #5 from Georg-Johann Lay <gjl at gcc dot gnu.org> ---
(In reply to Richard Sandiford from comment #4)
> (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?
avr_hard_regno_rename_ok and avr_hard_regno_scratch_ok require special handling
for the upper reg of FP.
> 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.
With the curret state of affairs, switching avr to LRA is not a good idea; you
can't even build neither libgcc nor libc.
Couldn't the elimination code in IRA / LRA just skip the high part? Or let
reload handle multi-reg FPs correctly, even though reload will come to an end?
Or maybe make eliminable regs an array that can be accessed in the backend, so
that avr.cc could adjust the entries in adjust_reg_alloc_order or
init_expanders to something like:
eliminables[3] = eliminables[2]
having a duplicate entry shouldn't hurt?
