Reload patch for PA call rewrite.

Reload patch for PA call rewrite.

[John David Anglin]

This patch is needed for the PA call rewrite.  It simply makes the
arg pointer live if it is used in the mem substitution being done
by reload.  It obviously should be live but never matter because I
doubt anyone has used a register that is not call clobbered for the
arg pointer.  The same might apply to the frame pointer but there is
another mechanism to determine when it is needed.

Tested on hppa64-hp-hpux11*, hppa2.0w-hp-hpux11* and hppa-unknown-linux-gnu
with no regressions.

Ok for main?

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

2002-10-23  John David Anglin  <dave@hiauly1.hia.nrc.ca>

	* reload1.c (reload): Make the arg pointer register live if the memory
	address that is used to eliminate a pseudo mentions it.

Index: reload1.c
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/reload1.c,v
retrieving revision 1.358
diff -u -3 -p -r1.358 reload1.c
--- reload1.c	30 Sep 2002 19:35:16 -0000	1.358
+++ reload1.c	9 Oct 2002 19:04:27 -0000
@@ -1167,6 +1167,17 @@ reload (first, global)
 		    = MEM_SCALAR_P (reg) = 0;
 		  MEM_ATTRS (reg) = 0;
 		}
+
+#ifdef CALL_REALLY_USED_REGISTERS
+	      /* The arg pointer register may not be really call used on
+		 targets that copy the incoming arg pointer to a call-saved
+		 fixed register.  In this case, the target needs to know
+		 whether or not the arg pointer register is ever live.  */
+	      if (!call_really_used_regs[ARG_POINTER_REGNUM]
+		  && !regs_ever_live[ARG_POINTER_REGNUM]
+		  && reg_mentioned_p (arg_pointer_rtx, addr))
+		regs_ever_live[ARG_POINTER_REGNUM] = 1;
+#endif
 	    }
 	  else if (reg_equiv_mem[i])
 	    XEXP (reg_equiv_mem[i], 0) = addr;

Re: Reload patch for PA call rewrite.

[Richard Henderson]

On Wed, Oct 23, 2002 at 04:33:50PM -0400, John David Anglin wrote:
> 	* reload1.c (reload): Make the arg pointer register live if the memory
> 	address that is used to eliminate a pseudo mentions it.

Why would this not be set earlier?


r~

Re: Reload patch for PA call rewrite.

[John David Anglin]

> On Wed, Oct 23, 2002 at 04:33:50PM -0400, John David Anglin wrote:
> > 	* reload1.c (reload): Make the arg pointer register live if the memory
> > 	address that is used to eliminate a pseudo mentions it.
> 
> Why would this not be set earlier?

Most times it is.  However, I found in testing that sometimes this
substitution is in fact the first explicit use of the arg pointer.
Up to this point, we have a pseudo with a REG_EQUIV note and this
doesn't make the register live.

This problem is probably hidden when the arg pointer can be
eliminated as the stack or frame pointer is used instead.  However,
we can't eliminate it on hppa64 because the outgoing arg pointer in
a function call is set based on the cumulative size of the outgoing
args of the callee and this varies from one callee to another.

The reason I need to know whether the arg pointer register is live
or not is to determine whether I need to save the register used for
the arg pointer and copy the incoming arg pointer to it.  The saved
value is restored in the prologue.  We still are ABI compatible and
inter-operate with HP compiled code since we save and restore the
register used for the arg pointer across function calls.

We need to use a fixed register for the arg pointer for tail and
sibling calls to work.  We have no free call-clobbered registers
that could be fixed.  Thus, a call-saved register must be used for
the arg pointer if we want tail and sibling calls to work.  I wasn't
sure that this would provide improved performance but it does seem
to help.  From looking at the code, I am sure tail calls help but
I am less sure about sibcalls.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: Reload patch for PA call rewrite.

[Jeff Law]

 In message <200210241822.g9OIM8gA026334@hiauly1.hia.nrc.ca>, "John David 
Anglin
 >the arg pointer if we want tail and sibling calls to work.  I wasn't
 >sure that this would provide improved performance but it does seem
 >to help.  From looking at the code, I am sure tail calls help but
 >I am less sure about sibcalls.
This is a legitimate concern.

Eliminating self recursion is almost definitely going to be a win.

Eliminating a generic tail call may be a lose, particularly on processors
which use a branch target stack as the call/return sites no longer match
perfectly -- thus causing a branch mis-predict penalty when the callee
returns.  This was something I've always wanted to measure for modern
PAs and ia32 implementations, but never got around to doing so.

Jeff

Re: Reload patch for PA call rewrite.

[John David Anglin]

> Eliminating a generic tail call may be a lose, particularly on processors
> which use a branch target stack as the call/return sites no longer match
> perfectly -- thus causing a branch mis-predict penalty when the callee
> returns.  This was something I've always wanted to measure for modern
> PAs and ia32 implementations, but never got around to doing so.

As far as I can tell, we currently don't implement the branch target
stack feature.  I can see that with my proposed PA2.0 additions to
various call sequences that this wouldn't be too hard to add.

Jeff, do you know which PA processors implement the branch target feature?

My concern about sibcalls was more basic.  We can't share frames
between the sibcall callee and caller.  So, the overhead for a sibcall
and regular call are essentially the same.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: Reload patch for PA call rewrite.

[Jeff Law]

 In message <200210241848.g9OIm8b3026422@hiauly1.hia.nrc.ca>, "John David 
Anglin" writes:
 >As far as I can tell, we currently don't implement the branch target
 >stack feature.  I can see that with my proposed PA2.0 additions to
 >various call sequences that this wouldn't be too hard to add.
FWIW, most processors which have this capability do it implicitly -- the
PA is the oddball here in that you have to enable the BTS by using
special opcodes for the branch/return.

Unfortunately I don't have information on what specific models of the PA8000
series implement the branch target stack.

 >My concern about sibcalls was more basic.  We can't share frames
 >between the sibcall callee and caller.  So, the overhead for a sibcall
 >and regular call are essentially the same.
That certainly lesses the potential benefits of sibcalls.  If you can't
share frames, then how can sibcalls work at all?

jeff

Re: Reload patch for PA call rewrite.

[John David Anglin]

>  >My concern about sibcalls was more basic.  We can't share frames
>  >between the sibcall callee and caller.  So, the overhead for a sibcall
>  >and regular call are essentially the same.
> That certainly lesses the potential benefits of sibcalls.  If you can't
> share frames, then how can sibcalls work at all?

That's a good question.  Currently, sibcall_epilogue just calls
hppa_expand_epilogue.  This causes all registers to be restored
and the stack adjusted.  Then, the sibcall is made and a new set
of registers are saved.  This is identical to what happens in
a regular call.  So, there is no benefit as far as I can see.

Ia64 seems to do pretty much the same as we do.

In the case of recursive tail calls, we do share the same frame
so there is a clear benefit.  That's the main benefit in using
a fixed arg pointer as opposed to one that's not fixed.

I did see a small but consistent improvement in the running time
of genattrtab with sibcalls enabled.  I don't know where this arises
but I doubt it is from any saving in the call sequence itself.
There are small differences in how the delay slot is used.  For
regular calls, we use a branch and link, and for sibcalls, we just
branch.  That's the sum of the differences as I see it.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: Reload patch for PA call rewrite.

[Richard Henderson]

On Wed, Oct 23, 2002 at 04:33:50PM -0400, John David Anglin wrote:
> 	* reload1.c (reload): Make the arg pointer register live if the memory
> 	address that is used to eliminate a pseudo mentions it.

This patch isn't correct.  You're doing this too late.  If
the argument pointer isn't live at this point, you won't have
allocated a spill slot for it, which means you'll have to add
one, which means that all your elimination offsets change.

You need to have this happen inside the something_changed
loop earlier in reload.


r~

Re: Reload patch for PA call rewrite.

[Richard Henderson]

On Thu, Oct 24, 2002 at 12:44:34PM -0600, Jeff Law wrote:
> Eliminating a generic tail call may be a lose, particularly on processors
> which use a branch target stack as the call/return sites no longer match
> perfectly

This is incorrect.  The return target stack is still intact.

Consider a()->b()->c().  If there are no tail calls, then
in C, the return stack is two deep, and we pop them both off
with two return instructions.  If B tail calls, then in C the
return stack is only one deep, and we pop that one off with
one return instruction.

I suppose it could make a difference to targets that don't
have a separate return instruction, and whose architecture
doesn't suggest a canonical return register.  (Examples of
the later is MIPS (indirect branch with r31) and PPC
(indirect branch with lr)).  I don't know how PA treats this.


r~

Re: Reload patch for PA call rewrite.

[Richard Henderson]

On Thu, Oct 24, 2002 at 05:49:09PM -0400, John David Anglin wrote:
> So, there is no benefit as far as I can see.

The benefit is

  (1) you have popped the local variables from the caller, 
      and so you've reduced the total stack space required.

  (2) you return directly to the caller's caller, which
      eliminates the little hunk of code in which we load
      the return address from memory and immediately use it
      to branch again.  In this little hunk we've got nothing
      to do but wait for memory latency.


r~

Re: Reload patch for PA call rewrite.

[John David Anglin]

> On Wed, Oct 23, 2002 at 04:33:50PM -0400, John David Anglin wrote:
> > 	* reload1.c (reload): Make the arg pointer register live if the memory
> > 	address that is used to eliminate a pseudo mentions it.
> 
> This patch isn't correct.  You're doing this too late.  If
> the argument pointer isn't live at this point, you won't have
> allocated a spill slot for it, which means you'll have to add
> one, which means that all your elimination offsets change.

Why do I need a spill lot for a fixed register?

I guess you point is that if this occurs on a target where the arg
pointer isn't fixed then there will be a problem because a spill
slot hasn't been allocated.  However, in that case, function.c copies
the arg pointer to a pseudo.  Won't that create a slot for it?

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: Reload patch for PA call rewrite.

[Richard Henderson]

On Fri, Oct 25, 2002 at 07:53:24PM -0400, John David Anglin wrote:
> Why do I need a spill lot for a fixed register?

Because it's call-saved, and you have to save and restore it somewhere.  


r~

Re: Reload patch for PA call rewrite.

[John David Anglin]

> On Fri, Oct 25, 2002 at 07:53:24PM -0400, John David Anglin wrote:
> > Why do I need a spill lot for a fixed register?
> 
> Because it's call-saved, and you have to save and restore it somewhere.  

This is done in the prologue after reload along with all the other
call-saved registers.  The frame size isn't determined until then.
We can't eliminate the arg pointer.  This seems to work fine for
the elimination of the frame pointer.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: Reload patch for PA call rewrite.

[Richard Henderson]

On Fri, Oct 25, 2002 at 08:20:20PM -0400, John David Anglin wrote:
> This is done in the prologue after reload along with all the other
> call-saved registers.  The frame size isn't determined until then.

Huh?  How can that be?  You've got to know how large your 
stack frame is...  The definition of virtual_cfa_rtx must
must be wrong for pa64.  So does dwarf2 EH work at all?


r~

Re: Reload patch for PA call rewrite.

[Richard Henderson]

On Fri, Oct 25, 2002 at 08:20:20PM -0400, John David Anglin wrote:
> > Because it's call-saved, and you have to save and restore it somewhere.  
> 
> This is done in the prologue after reload along with all the other
> call-saved registers.  The frame size isn't determined until then.

In any case, no matter how frames are allocated on PA, on most
other targets the register spill area is allocated and adjusted
during the something_changed loop.  IMO it's wrong for us to be
modifying register life data after that loop.


r~

Re: Reload patch for PA call rewrite.

[John David Anglin]

> Huh?  How can that be?  You've got to know how large your 
> stack frame is...  The definition of virtual_cfa_rtx must
> must be wrong for pa64.  So does dwarf2 EH work at all?

Not yet.  It's using sjlj exceptions at this point.  There
are still issues with the linker.  In fact, the arg pointer
offset to the stack pointer is not related to the frame size
but to the cumulative size of the outing args of the caller
which of course varies from one caller to another (and
compiler as the HP compiler does this slightly differently
than gcc).

The hppa-linux port is using dwarf2 EH.  It seems to work.
The only problem that I am aware of that might be related is
PR c++/8329 but this also was a problem before the dwarf2
implementation.  The difference there is that args grow
downward, so the offset to the first arg can always be
determined from the stack pointer.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: Reload patch for PA call rewrite.

[John David Anglin]

> In any case, no matter how frames are allocated on PA, on most
> other targets the register spill area is allocated and adjusted
> during the something_changed loop.  IMO it's wrong for us to be
> modifying register life data after that loop.

My question in that case is how do I determine whether or not the arg
pointer will actually be needed at an earlier point?

From what you have said, it is quite likely that we are allocating the
register spill area twice (something_change_loop and PA prologue).

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: Reload patch for PA call rewrite.

[John David Anglin]

> On Wed, Oct 23, 2002 at 04:33:50PM -0400, John David Anglin wrote:
> > 	* reload1.c (reload): Make the arg pointer register live if the memory
> > 	address that is used to eliminate a pseudo mentions it.
> 
> This patch isn't correct.  You're doing this too late.  If
> the argument pointer isn't live at this point, you won't have
> allocated a spill slot for it, which means you'll have to add
> one, which means that all your elimination offsets change.

This really isn't a problem although there was a problem with my
backend patch in this respect.  The backend simply has to always
allocate a slot so that that the elimination offsets are independent
of whether the arg pointer is live or not.

> You need to have this happen inside the something_changed
> loop earlier in reload.

I did some further investigation of this and there doesn't appear
to be a simple change to do this.  If I make the arg pointer an
eliminable register that can't be eliminated, spill_hard_reg
unconditionally makes it live.  This causes my backend code to
unconditionally save the arg pointer register, copy the incoming
arg pointer to the arg pointer, and then restore the arg pointer.
The overhead of this is significant in small functions and much
of the benefit in having tail calls is lost.

I experimented with not making the arg pointer unconditionally
live and still spilling it.  However, then I end up with the same
situation as when the arg pointer isn't an eliminable register.
The arg pointer can implicitly become alive when an incoming
argument is copied to a pseudo and that pseudo doesn't get a
hard register.  The only possible solutions to this are 1) somehow
move the final pseudo substition into the something_changed loop,
or 2) allocate slots for incoming arguments using the frame pointer.
I don't think 1) is possible as you don't know whether the pseudo
will get a hard register until the loop completes.  2) wastes stack
space as the PA64 ABI already reserves stack slots for the incoming
arguments in registers, albeit relative to the arg pointer.

So, I'm back to more or less my original patch with some modified
commentary.  I would argue that it can't be wrong to set regs_ever_live
for the arg pointer when the arg pointer is in fact live at some point
in the function.  If this somehow changes elimination offsets, that's
really a problem in the backend.  We could abort if this happens and
insist that the arg pointer be in the set of eliminable registers.
This would ensure that it is always spilled and alive when it can't
be eliminated.  However, I then would have to do a brute force scan
in the prologue to determine if the arg pointer is ever used.

Do you see any other approach?

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

2002-10-30  John David Anglin  <dave@hiauly1.hia.nrc.ca>

	* reload1.c (reload): Make the arg pointer live if it used in a
	substituted MEM.
	* doc/tm.texi (ARG_POINTER_REGNUM): Document that elimination offsets
	should not depend on the aliveness of the arg pointer when it is not
	an eliminable register.

Index: reload1.c
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/reload1.c,v
retrieving revision 1.363
diff -u -3 -p -r1.363 reload1.c
--- reload1.c	29 Oct 2002 17:47:12 -0000	1.363
+++ reload1.c	30 Oct 2002 19:17:16 -0000
@@ -1167,6 +1167,15 @@ reload (first, global)
 		    = MEM_SCALAR_P (reg) = 0;
 		  MEM_ATTRS (reg) = 0;
 		}
+
+	      /* The substitution may have made the arg pointer live if
+		 it isn't an eliminable register.  The target must ensure
+		 that the elimination offsets do not change when this
+		 happens as we are past the point where the offsets can
+		 change.  */
+	      if (!regs_ever_live[ARG_POINTER_REGNUM]
+		  && reg_mentioned_p (arg_pointer_rtx, addr))
+		regs_ever_live[ARG_POINTER_REGNUM] = 1;
 	    }
 	  else if (reg_equiv_mem[i])
 	    XEXP (reg_equiv_mem[i], 0) = addr;
Index: doc/tm.texi
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/doc/tm.texi,v
retrieving revision 1.179
diff -u -3 -p -r1.179 tm.texi
--- doc/tm.texi	20 Oct 2002 18:52:01 -0000	1.179
+++ doc/tm.texi	30 Oct 2002 19:17:22 -0000
@@ -3103,7 +3103,10 @@ frame pointer register.  On some machine
 register this is.  On other machines, you can choose any register you
 wish for this purpose.  If this is not the same register as the frame
 pointer register, then you must mark it as a fixed register according to
-@code{FIXED_REGISTERS}, or arrange to be able to eliminate it
+@code{FIXED_REGISTERS}, or arrange to be able to eliminate it.  If you
+don't define it as an eliminable register in @code{ELIMINABLE_REGS},
+then the backend must ensure that the elimination offsets do not depend
+on the liveness of the register
 (@pxref{Elimination}).
 
 @findex RETURN_ADDRESS_POINTER_REGNUM

Re: Reload patch for PA call rewrite.

[Richard Henderson]

On Fri, Oct 25, 2002 at 09:07:01PM -0400, John David Anglin wrote:
> My question in that case is how do I determine whether or not the arg
> pointer will actually be needed at an earlier point?

I'd expect that you could examine the reloads created by
find_reloads when called from calculate_needs_all_insns.


r~

Re: Reload patch for PA call rewrite.

[Richard Henderson]

On Wed, Oct 30, 2002 at 03:03:15PM -0500, John David Anglin wrote:
> This really isn't a problem although there was a problem with my
> backend patch in this respect.  The backend simply has to always
> allocate a slot so that that the elimination offsets are independent
> of whether the arg pointer is live or not.

This would mean that no leaf functions would ever have an
empty stack frame.  Badness.

> I did some further investigation of this and there doesn't appear
> to be a simple change to do this.  If I make the arg pointer an
> eliminable register that can't be eliminated...

No, this is not the tack I was indicating.  See the other
message I sent a moment ago.



r~

Re: Reload patch for PA call rewrite.

[John David Anglin]

> This would mean that no leaf functions would ever have an
> empty stack frame.  Badness.

Ah yes, you are correct.  There are a couple of extra instructions in a
leaf function.  I am tempted to store the arg pointer in the callers frame.
The HP compiler seems to allocate four extra slots beyond the two listed
in the ABI for the return pointer and previous stack pointer, so there
probably wouldn't be a problem in using one them.  However, I will take a
look at your suggestion.

I have been pondering whether the arg pointer needs to be spilled when
it is not an eliminable register.  This isn't done now.  However,
reload spills eliminable registers when they can't be eliminated.
So, is it necessary in this situation?

When the register is fixed, I don't think it is necessary unless it
is possible for overlaps to occur.  There never seem to be any pseudos
assigned directly when the register is fixed.  Overlaps couldn't occur
in the configuration that I was testing because I selected an even
register for the arg pointer and wide modes are constrained to start
on an even register.  If it is generally true that overlaps don't occur
when the register is fixed, then spill_hard_reg doesn't need to make
a pass through the pseudos when it is dealing with a fixed register.

In the current situation where it is not fixed, spilling appears to
result in a slight performance reduction although this is is based on
a rather limited amount of testing.  I am concerned that since the
register is used for multiple purposes and instantiate_new_reg
instantiates virtual_incoming_args_rtx using the arg_pointer_rtx
that there could be conficts.  However, I have never observed any.
Do you have an opinion on this?

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: Reload patch for PA call rewrite.

[John David Anglin]

> On Fri, Oct 25, 2002 at 09:07:01PM -0400, John David Anglin wrote:
> > My question in that case is how do I determine whether or not the arg
> > pointer will actually be needed at an earlier point?
> 
> I'd expect that you could examine the reloads created by
> find_reloads when called from calculate_needs_all_insns.

This is what I came up with.  After the arg pointer is spilled,
it will not be used as a reload register.  Thus, I don't think
that there are any circumstances in which a reload will make the
register live.  The only way it can become live is if a pseudo
with an equivalence that mentions the arg pointer doesn't get a
hard register.  So, I wrote a small routine to check for equivalences
that mention the arg pointer and set regs_ever_live for arg pointer
in the something changed_loop based on the result.

Tested with no regressions on hppa64-hp-hpux11.11.  The patch
definitely provides an improvement in performance when combined with
the PA backend patch to copy the incoming arg pointer to the new
fixed arg pointer.  So, I definitely think it is worthwhile.

Ok for main?

Dave
--
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

2002-11-02  John David Anglin  <dave@hiauly1.hia.nrc.ca>

	* reload1.c (reg_mentioned_in_equivs_p): New function.
	(reload): When the arg pointer is not eliminable, spill it and add it
	to the bad_spill_regs_global set.  If it is also not initially live,
	set regs_ever_live for the arg pointer in the something_changed loop
	to a state which which reflects whether or not it is mentioned in the
	equivalences for the remaining pseudos.  

Index: reload1.c
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/reload1.c,v
retrieving revision 1.363
diff -u -3 -p -r1.363 reload1.c
--- reload1.c	29 Oct 2002 17:47:12 -0000	1.363
+++ reload1.c	2 Nov 2002 20:22:54 -0000
@@ -367,6 +367,7 @@ static int num_labels;
 static void replace_pseudos_in_call_usage	PARAMS ((rtx *,
 							 enum machine_mode,
 							 rtx));
+static int reg_mentioned_in_equivs_p	PARAMS ((rtx));
 static void maybe_fix_stack_asms	PARAMS ((void));
 static void copy_reloads		PARAMS ((struct insn_chain *));
 static void calculate_needs_all_insns	PARAMS ((int));
@@ -668,6 +669,8 @@ reload (first, global)
      rtx first;
      int global;
 {
+  int arg_pointer_eliminable = 0;
+  int arg_pointer_init_ever_live;
   int i;
   rtx insn;
   struct elim_table *ep;
@@ -903,8 +906,24 @@ reload (first, global)
   if (frame_pointer_needed)
     spill_hard_reg (HARD_FRAME_POINTER_REGNUM, 1);
 #endif
+
+  /* The arg pointer needs special treatment when it is not eliminable.  */
+  for (ep = reg_eliminate; ep < &reg_eliminate[NUM_ELIMINABLE_REGS]; ep++)
+    if (ep->from == ARG_POINTER_REGNUM)
+      arg_pointer_eliminable = 1;
+
+  if (!arg_pointer_eliminable)
+    {
+      /* Kick pseudos out and make sure that the arg pointer is not used
+	 as a spill register.  */
+      spill_hard_reg (ARG_POINTER_REGNUM, 0);
+      SET_HARD_REG_BIT (bad_spill_regs_global, ARG_POINTER_REGNUM);
+    }
+
   finish_spills (global);
 
+  arg_pointer_init_ever_live = regs_ever_live[ARG_POINTER_REGNUM];
+
   /* From now on, we may need to generate moves differently.  We may also
      allow modifications of insns which cause them to not be recognized.
      Any such modifications will be cleaned up during reload itself.  */
@@ -1035,6 +1054,31 @@ reload (first, global)
 	    }
       }
 
+      /* When the arg pointer is both not eliminable and not initially
+	 ever live, we have to check whether there are any pseudos with
+	 equivalences that mention the arg pointer.  If there are, we
+	 need to treat the arg pointer as live as they will make the
+	 arg pointer live when they are substituted.  */
+      if (!arg_pointer_eliminable && !arg_pointer_init_ever_live)
+	{
+	  if (reg_mentioned_in_equivs_p (arg_pointer_rtx))
+	    {
+	      if (!regs_ever_live[ARG_POINTER_REGNUM])
+		{
+		  regs_ever_live[ARG_POINTER_REGNUM] = 1;
+		  something_changed = 1;
+		}
+	    }
+	  else
+	    {
+	      if (regs_ever_live[ARG_POINTER_REGNUM])
+		{
+		  regs_ever_live[ARG_POINTER_REGNUM] = 0;
+		  something_changed = 1;
+		}
+	    }
+	}
+
       select_reload_regs ();
       if (failure)
 	goto failed;
@@ -1293,6 +1337,32 @@ reload (first, global)
   unshare_all_rtl_again (first);
 
   return failure;
+}
+
+/* Return 1 if the register REG is mentioned in the equivalent mem or
+   address of any pseudo.  Otherwise, 0 is returned.  */
+static int
+reg_mentioned_in_equivs_p (reg)
+     rtx reg;
+{
+  int i;
+
+  for (i = FIRST_PSEUDO_REGISTER; i < max_regno; i++)
+    if (reg_renumber[i] < 0)
+      {
+	rtx addr = 0;
+
+	if (reg_equiv_mem[i])
+	  addr = XEXP (reg_equiv_mem[i], 0);
+
+	if (reg_equiv_address[i])
+	  addr = reg_equiv_address[i];
+
+	if (addr && reg_mentioned_p (reg, addr))
+	  return 1;
+      }
+
+  return 0;
 }
 
 /* Yet another special case.  Unfortunately, reg-stack forces people to

Re: Reload patch for PA call rewrite.

[John David Anglin]

>  In message <200210241848.g9OIm8b3026422@hiauly1.hia.nrc.ca>, "John David 
> Anglin" writes:
>  >As far as I can tell, we currently don't implement the branch target
>  >stack feature.  I can see that with my proposed PA2.0 additions to
>  >various call sequences that this wouldn't be too hard to add.
> FWIW, most processors which have this capability do it implicitly -- the
> PA is the oddball here in that you have to enable the BTS by using
> special opcodes for the branch/return.
> 
> Unfortunately I don't have information on what specific models of the PA8000
> series implement the branch target stack.

I have it from HP that there are no processors that implement the explicit
BTS opcodes described in the Kane book and that it is highly unlikely that
any future processors will have this feature.  However, there are PA
processors have a completely hardware managed BTS.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: Reload patch for PA call rewrite.

[Jeff Law]

 In message <200211152205.gAFM5920015687@hiauly1.hia.nrc.ca>, "John David 
Anglin
" writes:
 >I have it from HP that there are no processors that implement the explicit
 >BTS opcodes described in the Kane book and that it is highly unlikely that
 >any future processors will have this feature.  However, there are PA
 >processors have a completely hardware managed BTS.
For the hardware managed BTS machines we should probably disable sibling
call optimizations as they'll scrog the BTS.

jeff

Re: Reload patch for PA call rewrite.

[John David Anglin]

> For the hardware managed BTS machines we should probably disable sibling
> call optimizations as they'll scrog the BTS.

I think that depends on how they push the return pointer.  I'll see if
I can find out which processors have the feature.

In testing, I have noted one further complication regarding sibcalls
on hppa64-hpux.  If you build and install a compiler using the HP
linker and then try to do a bootstrap using the GNU linker, the build
will fail unless sibcalls are disabled because of the poor placement
of stubs using the GNU linker.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: Reload patch for PA call rewrite.

[Zack Weinberg]

On Sun, 2002-11-17 at 15:48, Jeff Law wrote:
> For the hardware managed BTS machines we should probably disable sibling
> call optimizations as they'll scrog the BTS.

I don't see how this would happen.  Sibcall optimization takes

a:
	...
	call b
	ret

b:
	...
	ret

and turns it into

a:
	...
	jmp b

b:
	...
	ret

Afterward, it's as if there was one long function with an unconditional
jump in the middle.  How does this scrog the BTS?

zw

Re: Reload patch for PA call rewrite.

[John David Anglin]

> On Sun, 2002-11-17 at 15:48, Jeff Law wrote:
> > For the hardware managed BTS machines we should probably disable sibling
> > call optimizations as they'll scrog the BTS.
> 
> I don't see how this would happen.  Sibcall optimization takes
> 
> a:
> 	...
> 	call b
> 	ret
> 
> b:
> 	...
> 	ret
> 
> and turns it into
> 
> a:
> 	...
> 	jmp b
> 
> b:
> 	...
> 	ret
> 
> Afterward, it's as if there was one long function with an unconditional
> jump in the middle.  How does this scrog the BTS?

"jmp b" and "ret" may be the same machine instruction.  The PA
architecture has a collection of branch instructions, but no
iexplicit call or ret instructions.  Thus, the jmp might scrog
the BTS.

The machine definition currently does short sibcalls using a
"B,L target,%r0" where %r0 is the link register.  As register %r0 is
a fixed 0, we are throwing away the link value in the sibcall.  This
instruction probably will not confuse the BTS hardware.  However, for
long sibcalls, we use the "BVE (b)" instruction.  This instruction is
also used for for function returns.  So, the hardware might have
some difficulty determining when to pop the BTS.  Possibly, only a
"BVE (%r2)" will pop the BTS and "BVE (%r1)" won't.  We use the former
for returns and the latter for long sibcalls.  However, I don't have
any information on how the hardware actually BTS works.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: Reload patch for PA call rewrite.

[Richard Henderson]

On Sun, Nov 17, 2002 at 04:48:38PM -0700, Jeff Law wrote:
> For the hardware managed BTS machines we should probably disable sibling
> call optimizations as they'll scrog the BTS.

I can't believe this is true.  Please explain to me why

	push
	push
	pop
	pop

maintains a stack while

	push
	jump
	pop

doesn't.


r~

Re: Reload patch for PA call rewrite.

[John David Anglin]

> I can't believe this is true.  Please explain to me why
> 
> 	push
> 	push
> 	pop
> 	pop
> 
> maintains a stack while
> 
> 	push
> 	jump
> 	pop
> 
> doesn't.

We don't have any documentation on how the PA hardware-manged BTS works.
All seven instructions in your example are branch instructions of one
flavor or another and we don't know specifically which instructions
affect the stack.  If "jump" was implemented as

	copy %rp,%r1
	b,l target,%rp
	copy %r1,%rp

what happens to the stack?  This might be useful for an intermediate
range sibcall since the maximum branch distance is a factor 32 larger
than a "b target" instruction.  However, it might push the stack.

With the BVE instruction, you want it to push in some situations,
pop in others, and not affect the stack in others.  The PA 2.0
architecture defines insn completers to specify what happens to the
BTS but they haven't been implemented.  Although I can guess what
might have been done in the fully hardware implementation, I don't
know for certain.

With our current call sequences, I doubt that sibcalls scrog the stack
as the "jump" implementation doesn't mention %rp (the return pointer).

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: Reload patch for PA call rewrite.

[John David Anglin]

> It's possible the improvements are on the return path side -- by returning
> to the caller's parent rather than the caller itself, we avoid one hard
> to predict branch (the "bv" in the caller) and maybe one easy to predict
> branch (branch to the epilogue).  

Yes, I can see that returns are hard to predict since they are indirect
and we save one with the sibcall.  We definitely should implement the BTS
for returns.

I tried the same test on hppa-linux and there wasn't any difference in
the timing with and without sibcalls.  I'm going to try 32-bit hpux.
Possibly, there is a linux/hpux difference.  Possibly, there is a
difference wrt the P bit in the ITLB between these systems.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: Reload patch for PA call rewrite.

[Jeff Law]

In message <200210242326.g9ONQkob027212@hiauly1.hia.nrc.ca>, "John David Anglin
" writes:
 >> I did see a small but consistent improvement in the running time
 >> of genattrtab with sibcalls enabled.  I don't know where this arises
 >> but I doubt it is from any saving in the call sequence itself.
 >> There are small differences in how the delay slot is used.  For
 >> regular calls, we use a branch and link, and for sibcalls, we just
 >> branch.  That's the sum of the differences as I see it.
 >
 >I just rechecked the above.  With the only change being the value for
 >FUNCTION_OK_FOR_SIBCALL, the times for genattrtab on an a500 running
 >hppa64-hp-hpux11.11 with the call rewrite were 13.24 seconds with
 >sibcalls and 13.71 seconds without sibcalls, respectively.  These
 >numbers are consistent with what I measured using an earlier version
 >of the patch.  I think the 3 percent improvement is worthwhile.
Definitely worthwhile.

It's possible the improvements are on the return path side -- by returning
to the caller's parent rather than the caller itself, we avoid one hard
to predict branch (the "bv" in the caller) and maybe one easy to predict
branch (branch to the epilogue).  

jeff

Re: Reload patch for PA call rewrite.

[John David Anglin]

> I did see a small but consistent improvement in the running time
> of genattrtab with sibcalls enabled.  I don't know where this arises
> but I doubt it is from any saving in the call sequence itself.
> There are small differences in how the delay slot is used.  For
> regular calls, we use a branch and link, and for sibcalls, we just
> branch.  That's the sum of the differences as I see it.

I just rechecked the above.  With the only change being the value for
FUNCTION_OK_FOR_SIBCALL, the times for genattrtab on an a500 running
hppa64-hp-hpux11.11 with the call rewrite were 13.24 seconds with
sibcalls and 13.71 seconds without sibcalls, respectively.  These
numbers are consistent with what I measured using an earlier version
of the patch.  I think the 3 percent improvement is worthwhile.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: Reload patch for PA call rewrite.

[John David Anglin]

> This problem is probably hidden when the arg pointer can be
> eliminated as the stack or frame pointer is used instead.  However,
> we can't eliminate it on hppa64 because the outgoing arg pointer in
> a function call is set based on the cumulative size of the outgoing
> args of the callee and this varies from one callee to another.

That should be caller, not callee.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)