From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7967 invoked by alias); 23 May 2003 18:39:50 -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 23620 invoked from network); 23 May 2003 18:19:49 -0000 Received: from unknown (HELO caduceus.sc.intel.com) (143.183.121.6) by sources.redhat.com with SMTP; 23 May 2003 18:19:49 -0000 Received: from petasus.sc.intel.com (petasus.sc.intel.com [10.3.253.4]) by caduceus.sc.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 h4NIIch22515 for ; Fri, 23 May 2003 18:18:38 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by petasus.sc.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 h4NIIZ115905 for ; Fri, 23 May 2003 18:18:35 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.42.29]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003052311235001583 for ; Fri, 23 May 2003 11:23:50 -0700 Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 23 May 2003 11:19:47 -0700 Message-ID: From: "Winalski, Paul" To: "'gcc@gcc.gnu.org'" Subject: RE: gcc and the IA64 ABI Date: Fri, 23 May 2003 18:41:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-SW-Source: 2003-05/txt/msg02118.txt.bz2 We are experimenting with taking advantage of non-default symbol visibility (i.e., restricting symbol preemption) to enable more aggressive optimizations, including dispensing with the caller save/restore of gp on external calls made via undefined external symbols with restricted (protected, hidden, or internal) visibility. As permitted by the ELF Spec, we are interpreting a declaration such as: void foo() __attribute__((visibility("protected"))); where foo is external to the current compilation unit, as an assertion by the programmer that foo(), although external, will be linked into the same component as the current compilation unit, and therefore will share the same gp value, and therefore calls to foo() can dispense with saving/restoring gp around the call. The part of the IA64 ABI under discussion restricts tail calls to undefined external symbols to those cases where the compiler knows that the target of the tail call will be in the same component (and hence share the same gp value) as the routine making the tail call. Essentially the same conditions as we are using for the optimization dispensing with the save/restore of gp around a call. Our study of the situation so far indicates that tail call opportunities on Itanium are quite limited. Use of the alloc instruction in the caller precludes tail calls, for example. 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. If you have evidence that tail call optimization is a significant performance win on Itanium, we'd love to hear about it before we go charging down the wrong path. Regards, -Paul Winalski, Intel Corporation