Am 07.09.24 um 19:51 schrieb H.J. Lu:
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?
I can't find RELOAD_ELIMINABLE_REGS anywhere.
So are you proposing a new hook macro?
Johann
