This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Proposed fix for 3.1 branch
- From: Richard Henderson <rth at redhat dot com>
- To: Richard Kenner <kenner at vlsi1 dot ultra dot nyu dot edu>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Wed, 29 May 2002 17:24:23 -0700
- Subject: Re: Proposed fix for 3.1 branch
- References: <10205292344.AA01318@vlsi1.ultra.nyu.edu>
On Wed, May 29, 2002 at 07:44:16PM -0400, Richard Kenner wrote:
> Also, I'm not fully sure I understand your suggested approach to this
> for 3.2, by the way.
Look at how calls are treated on Alpha with -mexplicit-relocs.
Before reload, we have just the call pattern. After reload, we use
peephole2 to separate out the gp reload (circa alpha.md:4517).
You'd do something similar for ia64. There are a couple of differences:
First, due to stop bits, you can't (easily) fall back on complicated
output patterns. You need to be able to split the call pattern even
when peep2 isn't being run.
Second, you're restoring the GP from a saved value rather than from
pc-relative arithmetic. This makes things easier since I think you
can just use define_split instead of define_peephole2, since you can
simply let an unused GP reload be deleted as dead code. But it also
makes things trickier since you want a call-saved register to hold
the old GP value. However, this can be done either
(1) With get_hard_reg_initial_val and a
(use (match_operand:DI N "register_operand" "+r"))
term attached to the call. I think the inout constraint is
required to get reload to pick a call-saved register.
Otherwise it'll consider the operand an input to the call
and pick a call-clobbered register. It's also possible
that that reload doesn't actually handle inout constraints
on calls properly, at which point,
(2) Special-case another register in struct ia64_frame_info.
I.e. we do the allocation for the gp save register in the
backend. This would be handled similar to how we already
treat reg_fp, reg_save_b0, etc.
The peep2/splitter would then insert the correct regno from
the pre-computed current_frame_info struct.
Also, you either have to
(a) Fix another register at the top of the locals
(LOC78 is next, iirc) so that you can be absolutely
certain of finding a free register or
(b) Be prepared to reload the GP from the stack, which
means either generating
(set gp (plus sp offset)) ; 14 bit offset
(set gp (mem gp))
or
(set gp offset) ; 22 or 64 bit offset
(set gp (plus sp gp))
(set gp (mem gp))
r~