This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch] PR21990
Denis Chertykov wrote on Dienstag, 6. September 2005 18:26 :
> I think that reload can try to check r28:r29 (frame pointer) for
> Pmode. (may be not today may be in the future)
> I'm worry about this.
It seems that reload does take it to be guaranteed that the frame pointer
register could always hold a Pmode object ;-). The result of
avr_hard_regno_mode_ok seems to be used only for the other registers, those
that are managed by the register allocator.
I am not too worried about an eventual problem in the future. Difficulty is
that the specification for the target macro HARD_REGNO_MODE_OK is not
sufficiently explicit for our problem. In order to prevent that we will be
having a reload change in the future that uses HARD_REGNO_MODE_OK
differently, we could add a note to the documentation. Maybe something like
HARD_REGNO_MODE_OK:
In case that the target needs more than one register for holding the complete
frame pointer, HARD_REGNO_MODE_OK needs return 0 if the following two
conditions are met:
1.) the function uses a frame pointer (frame_pointer_needed_p ())
2.) placing a value of mode MODE into consecutive registers starting in REGNO
would overwrite the frame pointer or part of it.
For the unlikely case that we *will* then have a problem in the future: If
reload is really changed (I hope at least my children will see this day :-) )
and complains that it could not place anything into the frame pointer: This
will be the very first thing that we will be seeing: At the very latest we
will be getting an ICE when gcc starts to compile libgcc2.
Forbidding to use r28:r29 completely is the only *really* safe solution I see
today for preventing clobbers of the frame pointer: PR21990 showed that *if*
we allow a Pmode object, reload *did* think "oh fine there's a free spill
register available!". The clean solution would certainly be to change
reload.c . But that is something I'd rather like to leave to initiated gcc
druids :-).
Yours,
Bjoern