This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Proposed fix for 3.1 branch

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

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))
		(set gp offset)			; 22 or 64 bit offset
		(set gp (plus sp gp))
		(set gp (mem gp))


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]