https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116326
--- Comment #6 from Richard Sandiford <rsandifo at gcc dot gnu.org> --- (In reply to Georg-Johann Lay from comment #5) > > 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. Sure, but I meant: remove it locally while testing/working on LRA support. > 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? I don't think we should make any permanent changes to support this kind of manipulation, since it's only needed during the transition.
