Re: Does gcc violate the ia64 ABI?

["H. J. Lu" <hjl@lucon.org>]

On Sat, May 17, 2003 at 11:10:17PM -0400, John David Anglin wrote:
> > > This is talking about what happens in a procedure call.  It's not talking
> > > about what happens to gp in the body of a procedure.  'c' and 'd' don't
> > > guarantee that gp won't be modified when a local call returns.  For that,
> > 
> > 'c' and 'd' require the compiler guarantees gp won't be modified when
> > a local call returns since gp will be the same at procedure entry and
> > exit.
> 
> That's not how I interpret them.  They say that gp will be valid at
> procedure entry and at procedure return.  The returning procedure is
> not bar if it does a tail call to another procedure.  So, I can't

Where did the psABI say that? You can't interpret something which is
is not there. Any procedure is a returning procedure, bar is included.

> see how you can argue that gp always will be preserved across local
> calls if tail calls are ok.
> 
> The last sentence in 'd' is not a requirement.  The same compiler

I was talking about the "At procedure return, gp must be valid." part.

> does both the tail call optimization and the local call optimization.
> So, it can decide to perform one or the other, or none in situations
> where there is an incompatibility.  I don't see that not being able
> to optimize calls known to be local is an ABI violation.  Generating
> tail calls might be an ABI violation but again I can't see how 'a' to
> 'd' explicitly rule them out.

The rule says gp much be valid at entry and exit, period. It states

---
The effect of the rules is that gp must be treated as scratch register
at the point of call (i.e., it must be saved by the caller), and it must
be preserved from entry to exit.
---

The only optimization allowed by the ia64 psABI is to skip save/restore
gp across a function call if you can prove gp won't be changed.


H.J.