Does gcc violate the ia64 ABI?

Does gcc violate the ia64 ABI?

[H. J. Lu]

I will open a bug in gcc bugzilla when conversion is done. In the
meantime, I opened

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=91056

The problem is gcc doesn't save/store gp across call. According to the
ia64 ABI, callee can change gp and gp must be saved/restore by caller
across calls. It is on page 5-2 in the Itanium Software Conventions
and Runtime Architecture Guide. Am I right?

# gcc -O2 -S x.c

H.J.
--x.c-
extern void foo ();
 
void
bar (void)
{
  foo ();
}
--x.s-
        .file   "x.c"
        .pred.safe_across_calls p1-p5,p16-p63
        .text
        .align 16
        .global bar#
        .proc bar#
bar:
        .prologue
        .body
        .bbb
        nop 0
        nop 0
        br.sptk.many foo#
        ;;
        break.f 0
        ;;
        .endp bar#
        .ident  "GCC: (GNU) 3.2.3 20030422 (Red Hat Linux 3.2.3-3)"

Re: Does gcc violate the ia64 ABI?

[Andreas Schwab]

"H. J. Lu" <hjl@lucon.org> writes:

|> I will open a bug in gcc bugzilla when conversion is done. In the
|> meantime, I opened
|> 
|> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=91056
|> 
|> The problem is gcc doesn't save/store gp across call. According to the
|> ia64 ABI, callee can change gp and gp must be saved/restore by caller
|> across calls. It is on page 5-2 in the Itanium Software Conventions
|> and Runtime Architecture Guide. Am I right?

I don't see where's the problem.  If a function does not use a
call-clobbered register there is no need for saving/restoring it.  It's
the duty of the caller to do it.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Does gcc violate the ia64 ABI?

[H. J. Lu]

On Sat, May 17, 2003 at 12:09:58AM +0200, Andreas Schwab wrote:
> "H. J. Lu" <hjl@lucon.org> writes:
> 
> |> I will open a bug in gcc bugzilla when conversion is done. In the
> |> meantime, I opened
> |> 
> |> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=91056
> |> 
> |> The problem is gcc doesn't save/store gp across call. According to the
> |> ia64 ABI, callee can change gp and gp must be saved/restore by caller
> |> across calls. It is on page 5-2 in the Itanium Software Conventions
> |> and Runtime Architecture Guide. Am I right?
> 
> I don't see where's the problem.  If a function does not use a
> call-clobbered register there is no need for saving/restoring it.  It's
> the duty of the caller to do it.

gp is a special register in the ia64 ABI:

On page 5-2 in Itanium Software Conventions and Runtime Architecture
Guide, there are

...
a. On entry to a procedure, gp is guaranteed valide for that procedure.
b. At any direct procedure call, gp must be valid (for the caller). This
guarantees that an import stub (see Section 8.4.1) can access the linkage
table.
c. Any procedure call (indirect or direct) may modify gp - unless the call
is known to be local to the load module.
d. At procedure return, gp must be valid (for the returning prodecure).
This allows the compiler to optimize calls known to be local (i.e., the
exceptions to Rule 'c').

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.

Since bar () may modify gp, at the return of foo, gp must be valid for foo
even if foo doesn't use gp at all. Did I miss something here?


H.J.

Re: Does gcc violate the ia64 ABI?

[Richard Henderson]

On Fri, May 16, 2003 at 03:25:08PM -0700, H. J. Lu wrote:
> d. At procedure return, gp must be valid (for the returning prodecure).
> This allows the compiler to optimize calls known to be local (i.e., the
> exceptions to Rule 'c').

I was not aware of this clause.  I'd have sworn it wasn't a part
of the ABI at one time...

Indeed, if this clause is truely correct, then virtually all of
the tail-call possibilities on ia64 are invalid.  Yes, statics
still can be done, but that's not nearly as frequent.

Can you find out when this got added to the ABI?


r~

Re: Does gcc violate the ia64 ABI?

[H. J. Lu]

On Fri, May 16, 2003 at 05:43:18PM -0700, Richard Henderson wrote:
> On Fri, May 16, 2003 at 03:25:08PM -0700, H. J. Lu wrote:
> > d. At procedure return, gp must be valid (for the returning prodecure).
> > This allows the compiler to optimize calls known to be local (i.e., the
> > exceptions to Rule 'c').
> 
> I was not aware of this clause.  I'd have sworn it wasn't a part
> of the ABI at one time...
> 
> Indeed, if this clause is truely correct, then virtually all of
> the tail-call possibilities on ia64 are invalid.  Yes, statics
> still can be done, but that's not nearly as frequent.

Gcc can skip gp save/restore across a local call. Right now, gcc
saves and restores gp across a local call.

> 
> Can you find out when this got added to the ABI?
> 

Sure. BTW, the current one is dated May, 2001.


H.J.

Re: Does gcc violate the ia64 ABI?

[Richard Henderson]

On Fri, May 16, 2003 at 06:45:22PM -0700, H. J. Lu wrote:
> Gcc can skip gp save/restore across a local call. Right now, gcc
> saves and restores gp across a local call.

Indeed, but it also tail-calls to non-local functions, so
gcc is going to have a compatibility problem if we change
the ABI.


r~

Re: Does gcc violate the ia64 ABI?

[H. J. Lu]

On Sat, May 17, 2003 at 11:15:59AM -0700, Richard Henderson wrote:
> On Fri, May 16, 2003 at 06:45:22PM -0700, H. J. Lu wrote:
> > Gcc can skip gp save/restore across a local call. Right now, gcc
> > saves and restores gp across a local call.
> 
> Indeed, but it also tail-calls to non-local functions, so
> gcc is going to have a compatibility problem if we change
> the ABI.
> 

That is very unfortunate. We have several choices:

1. Do nothing. It is very bad.
2. Fix gcc and use a bit in ELF header to indicate the ABI change.
Linker will make sure no mixed .o/.so files.
3. Fix gcc and use a special empty note section to indicate the ABI
change. Linker will make sure no mixed .o/.so files.

I prefer 3, 2, 1, in that order.

BTW, Clause 'd' is in my Sept. 2000 copy of the runtime guide. It may
have been there for a long time. We must have missed it somehow.


H.J.

Re: Does gcc violate the ia64 ABI?

[Richard Henderson]

On Sat, May 17, 2003 at 01:43:17PM -0700, H. J. Lu wrote:
> 2. Fix gcc and use a bit in ELF header to indicate the ABI change.
> Linker will make sure no mixed .o/.so files.
> 3. Fix gcc and use a special empty note section to indicate the ABI
> change. Linker will make sure no mixed .o/.so files.

Neither of these are viable.  Some other, presumably conforming
psABI compiler will not emit either of these.

> BTW, Clause 'd' is in my Sept. 2000 copy of the runtime guide. It may
> have been there for a long time. We must have missed it somehow.

Hardly conclusive.  We need to go back to at least 1998 
to know if someone changed the ABI out from under us.


r~

Re: Does gcc violate the ia64 ABI?

[H. J. Lu]

On Sat, May 17, 2003 at 04:59:28PM -0700, Richard Henderson wrote:
> On Sat, May 17, 2003 at 01:43:17PM -0700, H. J. Lu wrote:
> > 2. Fix gcc and use a bit in ELF header to indicate the ABI change.
> > Linker will make sure no mixed .o/.so files.
> > 3. Fix gcc and use a special empty note section to indicate the ABI
> > change. Linker will make sure no mixed .o/.so files.
> 
> Neither of these are viable.  Some other, presumably conforming
> psABI compiler will not emit either of these.

It is a problem for those conforming compilers who have to use
libraries compiled with gcc. We can talk to them and ask them what
they think. If they want to safely optimize the code, they may come
up with something everyone can live with.

> 
> > BTW, Clause 'd' is in my Sept. 2000 copy of the runtime guide. It may
> > have been there for a long time. We must have missed it somehow.
> 
> Hardly conclusive.  We need to go back to at least 1998 
> to know if someone changed the ABI out from under us.
> 

I have asked. I will let you know what I find out. But it won't
change the unfortunate fact that gcc doesn't conform to the ia64
psABI, which everyone has to live with. I hope we can find some
kind of solution.


H.J.

Re: Does gcc violate the ia64 ABI?

[H. J. Lu]

On Sat, May 17, 2003 at 04:59:28PM -0700, Richard Henderson wrote:
> 
> > BTW, Clause 'd' is in my Sept. 2000 copy of the runtime guide. It may
> > have been there for a long time. We must have missed it somehow.
> 
> Hardly conclusive.  We need to go back to at least 1998 
> to know if someone changed the ABI out from under us.
> 

March 15, 1999, version 2.4E has the same wording. Oct. 10, 1997,
version 2.3E says

---
The gp value is always valid on entry to a procedure, and must be
valid at any procedure call. At procedure exit, the gp register
must contain either the procedure own gp, or a valid gp value
remaining from a call. In other words, this register should be
treated as a scratch register across calls (that is, a call may
destroy the register), but it must be preserved and restored prior
to procedure exit if used for any purpose other than holding the gp
value. (See the rationale in Section 5.8.)
...

5.8 Rationale
...
The gp register must be preserved by the procedure from entry to exit.
At procedure return, gp must be valid (for the returning procedure).
This allows the compiler to optimize calls known to be local.
---


H.J.

Re: Does gcc violate the ia64 ABI?

[Richard Henderson]

On Tue, May 20, 2003 at 03:58:54PM -0700, H. J. Lu wrote:
> March 15, 1999, version 2.4E has the same wording. Oct. 10, 1997,
> version 2.3E says

Ok, we just missed it.  I guess we're going to have to 
have a flag day for gcc ia64...


r~

Re: Does gcc violate the ia64 ABI?

[Richard Henderson]

On Mon, May 19, 2003 at 08:10:23AM -0700, H. J. Lu wrote:
> On Mon, May 19, 2003 at 05:02:00PM +0200, Jakub Jelinek wrote:
> > On Mon, May 19, 2003 at 07:55:40AM -0700, H. J. Lu wrote:
> > > > Only tail calls to provably local functions, apparently.
> > > > I think that's pretty stupid, considering how cheap it is
> > > > to reload the gp...
> > > 
> > > I disagree. Gcc can still do tail calls to external functions as long
> > > as it reloads gp, which gcc is already doing when gp is used after
> > > the call, like in this code
> > > 
> > > ---
> > > extern void bar ();
> > > 
> > > static void
> > > bar1 ()
> > > {
> > >   bar ();
> > > }
> > > 
> > > extern int x;
> > > 
> > > void
> > > foo ()
> > > {
> > >   bar1 ();
> > >   x += 1;
> > > }
> > > ---
> > > 
> > > I think we just need to change the code from
> > > 
> > > 	reload_gp = gp is used after the tail call
> > > 
> > > to
> > > 
> > > 	reload_gp = the tail call is external
> > > 
> > > It may be a win since we won't reload gp for the local call even if
> > > gp is used after the tail call. Besides, you have said reloading gp
> > > is cheap. I don't see fixing gcc will hurt performance.
> > 
> > If bar1 has to reload gp after bar returns, then certainly the call to bar
> > cannot be a tail call (as a tail call returns from bar stright to foo).
> 
> You reload gp when you do tail call expansion in foo, not in bar1.
> But bar1 has to reload gp if it isn't expanded. I don't know if gcc
> has the infrastructure to support that.

You're not making any sense at all.

Either the GP has to be valid for the target after the call
or it doesn't.  If bar1 tail-calls to bar, then the GP isn't
valid for bar1.

Unless you're going to claim that there's a different ABI for
functions called indirectly.  (Though bar1 can't be called by
name from a different TU, it can be called via function pointer.)

And, no matter what, you couldn't tail-call to an external 
routine from a non-static function.



r~

Re: Does gcc violate the ia64 ABI?

[H. J. Lu]

On Mon, May 19, 2003 at 05:02:00PM +0200, Jakub Jelinek wrote:
> On Mon, May 19, 2003 at 07:55:40AM -0700, H. J. Lu wrote:
> > > Only tail calls to provably local functions, apparently.
> > > I think that's pretty stupid, considering how cheap it is
> > > to reload the gp...
> > 
> > I disagree. Gcc can still do tail calls to external functions as long
> > as it reloads gp, which gcc is already doing when gp is used after
> > the call, like in this code
> > 
> > ---
> > extern void bar ();
> > 
> > static void
> > bar1 ()
> > {
> >   bar ();
> > }
> > 
> > extern int x;
> > 
> > void
> > foo ()
> > {
> >   bar1 ();
> >   x += 1;
> > }
> > ---
> > 
> > I think we just need to change the code from
> > 
> > 	reload_gp = gp is used after the tail call
> > 
> > to
> > 
> > 	reload_gp = the tail call is external
> > 
> > It may be a win since we won't reload gp for the local call even if
> > gp is used after the tail call. Besides, you have said reloading gp
> > is cheap. I don't see fixing gcc will hurt performance.
> 
> If bar1 has to reload gp after bar returns, then certainly the call to bar
> cannot be a tail call (as a tail call returns from bar stright to foo).

You reload gp when you do tail call expansion in foo, not in bar1.
But bar1 has to reload gp if it isn't expanded. I don't know if gcc
has the infrastructure to support that.


H.J.

Re: Does gcc violate the ia64 ABI?

[Jakub Jelinek]

On Mon, May 19, 2003 at 07:55:40AM -0700, H. J. Lu wrote:
> > Only tail calls to provably local functions, apparently.
> > I think that's pretty stupid, considering how cheap it is
> > to reload the gp...
> 
> I disagree. Gcc can still do tail calls to external functions as long
> as it reloads gp, which gcc is already doing when gp is used after
> the call, like in this code
> 
> ---
> extern void bar ();
> 
> static void
> bar1 ()
> {
>   bar ();
> }
> 
> extern int x;
> 
> void
> foo ()
> {
>   bar1 ();
>   x += 1;
> }
> ---
> 
> I think we just need to change the code from
> 
> 	reload_gp = gp is used after the tail call
> 
> to
> 
> 	reload_gp = the tail call is external
> 
> It may be a win since we won't reload gp for the local call even if
> gp is used after the tail call. Besides, you have said reloading gp
> is cheap. I don't see fixing gcc will hurt performance.

If bar1 has to reload gp after bar returns, then certainly the call to bar
cannot be a tail call (as a tail call returns from bar stright to foo).

	Jakub

Re: Does gcc violate the ia64 ABI?

[H. J. Lu]

On Sun, May 18, 2003 at 10:38:55PM -0700, Richard Henderson wrote:
> On Mon, May 19, 2003 at 01:01:39PM +1000, Fergus Henderson wrote:
> > If the ABI can't support tail calls, then I'd say the ABI is broken,
> > and should be replaced, not GCC.
> 
> Only tail calls to provably local functions, apparently.
> I think that's pretty stupid, considering how cheap it is
> to reload the gp...

I disagree. Gcc can still do tail calls to external functions as long
as it reloads gp, which gcc is already doing when gp is used after
the call, like in this code

---
extern void bar ();

static void
bar1 ()
{
  bar ();
}

extern int x;

void
foo ()
{
  bar1 ();
  x += 1;
}
---

I think we just need to change the code from

	reload_gp = gp is used after the tail call

to

	reload_gp = the tail call is external

It may be a win since we won't reload gp for the local call even if
gp is used after the tail call. Besides, you have said reloading gp
is cheap. I don't see fixing gcc will hurt performance.


H.J.

Re: Does gcc violate the ia64 ABI?

[Richard Henderson]

On Mon, May 19, 2003 at 01:01:39PM +1000, Fergus Henderson wrote:
> If the ABI can't support tail calls, then I'd say the ABI is broken,
> and should be replaced, not GCC.

Only tail calls to provably local functions, apparently.
I think that's pretty stupid, considering how cheap it is
to reload the gp...


r~

Re: Does gcc violate the ia64 ABI?

[Fergus Henderson]

On 18-May-2003, John David Anglin <dave@hiauly1.hia.nrc.ca> wrote:
> > 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.
> 
> > A violation is a violation. There is no slight violation.
> 
> Okay officer you got me, don't shoot!  You already got me in the leg.
> I promise I won't do any more of those nasty tail calls, use thunks or
> jump on trampolines ...

If the ABI can't support tail calls, then I'd say the ABI is broken,
and should be replaced, not GCC.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.

Re: Does gcc violate the ia64 ABI?

[John David Anglin]

> 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.

> A violation is a violation. There is no slight violation.

Okay officer you got me, don't shoot!  You already got me in the leg.
I promise I won't do any more of those nasty tail calls, use thunks or
jump on trampolines ...

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

Re: Does gcc violate the ia64 ABI?

[H. J. Lu]

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.

Re: Does gcc violate the ia64 ABI?

[John David Anglin]

> > 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
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
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.

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

Re: Does gcc violate the ia64 ABI?

[H. J. Lu]

On Sat, May 17, 2003 at 06:23:44PM -0400, John David Anglin wrote:
> >  
> > 
> >  That is safe according to the ia64 psABI.
> 
> Read carefully what 'c' says:
> 
> > c. Any procedure call (indirect or direct) may modify gp - unless the call
> > is known to be local to the load module.
> 
> 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.

> you need to know if it is valid for a function to make an external
> tail call, what happens to gp in the return path, etc.

Basically, an ia64 psABI conforming compiler should save/restore gp
across an external call no matter if gp is used by caller or not.


H.J.

Re: Does gcc violate the ia64 ABI?

[John David Anglin]

> > > Gcc can skip gp save/restore across a local call. Right now, gcc
> > > saves and restores gp across a local call.
> > 
> > Your example shows a tail-call to foo.  Gp is obviously valid at the call.
> > There is no return in your example, so 'd' doesn't apply.
> > 
> 
> What did you by "no return"? Where does it go?

The return is in "foo".  A tall call to an external function may
change gp.

> > two optimizations is more beneficial.  I would judge that the latter
> > treatment would be in slight violation of the ia64 ABI, but the violation
> > would be local to a translation unit.
> 
> A violation is a violation. There is no slight violation.

I was describing the pa treatment where there isn't similar wording
about the validity of gp at procedure return.

> > We currently do the latter optimization on the pa but I am wondering
> > if it would be better to skip the gp save/restore across local calls
> > instead.
>  
> 
>  That is safe according to the ia64 psABI.

Read carefully what 'c' says:

> c. Any procedure call (indirect or direct) may modify gp - unless the call
> is known to be local to the load module.

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,
you need to know if it is valid for a function to make an external
tail call, what happens to gp in the return path, etc.

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

Re: Does gcc violate the ia64 ABI?

[H. J. Lu]

On Sat, May 17, 2003 at 02:58:29PM -0400, John David Anglin wrote:
> > On Fri, May 16, 2003 at 05:43:18PM -0700, Richard Henderson wrote:
> > > On Fri, May 16, 2003 at 03:25:08PM -0700, H. J. Lu wrote:
> > > > d. At procedure return, gp must be valid (for the returning prodecure).
> > > > This allows the compiler to optimize calls known to be local (i.e., the
> > > > exceptions to Rule 'c').
> > > 
> > > I was not aware of this clause.  I'd have sworn it wasn't a part
> > > of the ABI at one time...
> > > 
> > > Indeed, if this clause is truely correct, then virtually all of
> > > the tail-call possibilities on ia64 are invalid.  Yes, statics
> > > still can be done, but that's not nearly as frequent.
> > 
> > Gcc can skip gp save/restore across a local call. Right now, gcc
> > saves and restores gp across a local call.
> 
> Your example shows a tail-call to foo.  Gp is obviously valid at the call.
> There is no return in your example, so 'd' doesn't apply.
> 

What did you by "no return"? Where does it go?

> Note that skipping the gp save/restore across a local call is a "compiler"
> optimization.  If you save and restore gp across local calls, then
> it's likely possible to skip the save and restore across the last call in
> a function if gp is not used after the last call, including the return
> path to the caller.  I don't have a good feeling as to which of these

You don't have to save and restore gp as long as you can prove gp is
not changed. It has nothing to do if gp is used or not, according to
the ia64 psABI.

> two optimizations is more beneficial.  I would judge that the latter
> treatment would be in slight violation of the ia64 ABI, but the violation
> would be local to a translation unit.

A violation is a violation. There is no slight violation.

> 
> We currently do the latter optimization on the pa but I am wondering
> if it would be better to skip the gp save/restore across local calls
> instead.
 

 That is safe according to the ia64 psABI.


 H.J.

Re: Does gcc violate the ia64 ABI?

[John David Anglin]

> On Fri, May 16, 2003 at 05:43:18PM -0700, Richard Henderson wrote:
> > On Fri, May 16, 2003 at 03:25:08PM -0700, H. J. Lu wrote:
> > > d. At procedure return, gp must be valid (for the returning prodecure).
> > > This allows the compiler to optimize calls known to be local (i.e., the
> > > exceptions to Rule 'c').
> > 
> > I was not aware of this clause.  I'd have sworn it wasn't a part
> > of the ABI at one time...
> > 
> > Indeed, if this clause is truely correct, then virtually all of
> > the tail-call possibilities on ia64 are invalid.  Yes, statics
> > still can be done, but that's not nearly as frequent.
> 
> Gcc can skip gp save/restore across a local call. Right now, gcc
> saves and restores gp across a local call.

Your example shows a tail-call to foo.  Gp is obviously valid at the call.
There is no return in your example, so 'd' doesn't apply.

Note that skipping the gp save/restore across a local call is a "compiler"
optimization.  If you save and restore gp across local calls, then
it's likely possible to skip the save and restore across the last call in
a function if gp is not used after the last call, including the return
path to the caller.  I don't have a good feeling as to which of these
two optimizations is more beneficial.  I would judge that the latter
treatment would be in slight violation of the ia64 ABI, but the violation
would be local to a translation unit.

We currently do the latter optimization on the pa but I am wondering
if it would be better to skip the gp save/restore across local calls
instead.

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

Re: Does gcc violate the ia64 ABI?

[John David Anglin]

> The problem is gcc doesn't save/store gp across call. According to the
> ia64 ABI, callee can change gp and gp must be saved/restore by caller
> across calls. It is on page 5-2 in the Itanium Software Conventions
> and Runtime Architecture Guide. Am I right?
> 
> # gcc -O2 -S x.c
> 
> H.J.
> --x.c-
> extern void foo ();
>  
>  void
>  bar (void)
>  {
>    foo ();
>  }

As on the PA, I don't believe there is a need to always save and restore
gp.  gp isn't used in bar.  The caller of bar will restore gp if it
uses gp after calling bar.  If bar called foo twice, then gp should
be saved and restored across the first call to foo.

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