On Sat, Sep 7, 2024 at 10:49 AM Georg-Johann Lay <a...@gjlay.de> wrote: > > Am 07.09.24 um 18:35 schrieb Jeff Law: > > On 9/6/24 3:40 AM, Georg-Johann Lay wrote: > >> The reason for PR116326 is that LRA and reload require different > >> ELIMINABLE_REGS for a multi-register frame pointer. As ELIMINABLE_REGS > >> is used to initialize static const objects, it is not possible to make > >> ELIMINABLE_REGS to depend on options or patch it in some target hook. > >> > >> It was also concluded that it is not desirable to adjust reload so that > >> it behaves like LRA, but a hack like #define IN_RELOAD1_CC at the top > >> of reload1.cc would be fine, see > >> > >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116326#c8 > >> > >> This is an according patch that defines IN_RELOAD1_CC and uses it in > >> avr.h to define ELIMINABLE_REGS. > >> > >> This is only required for trunk. > >> > >> PR116326 occurred for some test case in avr-torture.exp, so I didn't > >> duplicate the test case. > >> > >> As it appears, this patch also fixes: > >> > >> https://gcc.gnu.org/PR116324 > >> https://gcc.gnu.org/PR116325 > >> https://gcc.gnu.org/PR116550 > >> > >> Johann > >> > >> -- > >> > >> AVR: target/116326 - Adjust ELIMINABLE_REGS to reload resp. LRA. > >> > >> PR target/116326 > >> gcc/ > >> * reload1.cc (IN_RELOAD1_CC): Define prior to all includes. > >> * config/avr/avr.h (ELIMINABLE_REGS): Depend on IN_RELOAD1_CC. > > I'm going to have to NAK this. It's too hackish, even with reload going > > away.... > > > > Jeff > > So what is your proposal? > > I'd agree with Richard that we don't want to change reload > implementations such that they agree on ELIMINABLE_REGS. > > A different way would be to change reload1.cc such that it includes > reload.h prior to tm.h, i.e. prior to backend.h. This would make the > hack avr realm entirely, but it won't be trivially no-op. > > Johann
Why not add RELOAD_ELIMINABLE_REGS and default it to ELIMINABLE_REGS? -- H.J.
