From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31041 invoked by alias); 28 May 2003 14:38:03 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 30891 invoked from network); 28 May 2003 14:37:58 -0000 Received: from unknown (HELO hermes.fm.intel.com) (192.55.52.18) by sources.redhat.com with SMTP; 28 May 2003 14:37:58 -0000 Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by hermes.fm.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id h4SEXYI05877 for ; Wed, 28 May 2003 14:33:34 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by talaria.fm.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h4SEcfI20631 for ; Wed, 28 May 2003 14:38:41 GMT Received: from fmsmsx26.fm.intel.com ([132.233.42.26]) by fmsmsxvs041.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003052807345102651 ; Wed, 28 May 2003 07:34:51 -0700 Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 28 May 2003 07:37:56 -0700 Message-ID: From: "Winalski, Paul" To: "'Steve Ellcey'" , gcc@gcc.gnu.org, rth@redhat.com Subject: RE: gcc and the IA64 ABI Date: Wed, 28 May 2003 15:12:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-SW-Source: 2003-05/txt/msg02337.txt.bz2 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