RE: gcc and the IA64 ABI

["Winalski, Paul" <paul dot winalski at intel dot com>]

Actually, I was speaking about our (Intel's) compiler, not gcc.

-Paul W.

-----Original Message-----
From: Steve Ellcey [mailto:sje@cup.hp.com]
Sent: Friday, May 23, 2003 4:36 PM
To: Winalski, Paul; gcc@gcc.gnu.org; rth@redhat.com
Subject: RE: gcc and the IA64 ABI


> > But eliminating caller gp save/restore
> > seems to be promising.  Early testing seems to indicate significant
> > improvement on some important programs; we're still in the process of
> > collecting performance data.
> 
> I wouldn't have suspected that this would produce that much of a win,
> given that restoring the gp is so cheap; just a single mov instruction.

I wonder if the speed up is you are seeing is due to a side-effect of
how the GP is saved and restored.  GCC on IA64 was (is?)  using a single
register to save/restore gp and it always used the same register.  This
made otherwise loop invariant function calls (like integer division with
loop invariant arguments) look like they were never loop-invariant and
could not be moved out of the loop, especially when there were multiple
divisions (all loop invariant) in one loop.  See
http://gcc.gnu.org/ml/gcc-patches/2002-03/msg00179.html for a change I
proposed that allowed loop invariant code motion of calls, this change
was not checked in and I believe this situation still exists in 3.3.  It
may have been fixed on the top-of-tree as the way calls are expanded has
been changed and the routine ia64_gp_save_reg no longer exists.  See
http://gcc.gnu.org/ml/gcc-patches/2003-03/msg01196.html for where that
was removed by Richard Henderson.

Steve Ellcey
sje@cup.hp.com