From owner-pro64-support@oss.sgi.com Wed May 2 11:02:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f42I2g821143 for pro64-support-outgoing; Wed, 2 May 2001 11:02:42 -0700 Received: from serenity.mcc.ac.uk (serenity.mcc.ac.uk [130.88.200.93]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42I2eF21140 for ; Wed, 2 May 2001 11:02:41 -0700 Received: from nessie.mcc.ac.uk ([130.88.200.20] ident=root) by serenity.mcc.ac.uk with esmtp (Exim 2.05 #4) id 14v0xT-0004L7-00 for pro64-support@oss.sgi.com; Wed, 2 May 2001 19:02:39 +0100 Received: from localhost (zzcgusp@localhost) by nessie.mcc.ac.uk (8.9.3/8.8.8) with ESMTP id TAA08010 for ; Wed, 2 May 2001 19:02:39 +0100 (BST) (envelope-from zzcgusp@nessie.mcc.ac.uk) Date: Wed, 2 May 2001 19:02:38 +0100 (BST) From: Stephen Pickles Reply-To: Stephen Pickles To: Pro64 Support Subject: sgif90 -listing Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pro64-support@oss.sgi.com Precedence: bulk When I specify the -listing option to sgif90, I see a segmentation fault: [zzcgusp@fourier1 src]$ sgif90 -listing hello.f90 Signal: Segmentation fault in Front End Parse/Semantic phase. "hello.f90": Error: Signal Segmentation fault in phase Front End Parse/Semantic -- processing aborted sgif90 ERROR: /usr/lib/gcc-lib/ia64-sgi-linux/sgicc-1.0/mfef90 died due to signal 4 sgif90 ERROR: core dumped Do you see this too? I'm running compiler version 0.01.0-13 on a dual processor Troon (B1 stepping). The same problem occured at 0.01.0-12. It doesn't seem to matter what the source file is. Best wishes, Stephen ==================== Stephen M. Pickles ==================== CSAR Technology Refresh Team Leader s.pickles@man.ac.uk Manchester Computing Room G49-B, Kilburn Building tel: +44 161 275 5974 The University of Manchester fax: +44 161 275 6800 Oxford Road Manchester M13 9PL http://www.csar.cfs.ac.uk/ ===========================(*,*)============================ From owner-pro64-support@oss.sgi.com Wed May 2 12:22:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f42JMw731848 for pro64-support-outgoing; Wed, 2 May 2001 12:22:58 -0700 Received: from olsen.capsl.udel.edu (olsen.capsl.udel.edu [128.4.10.3]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42JMuF31828 for ; Wed, 2 May 2001 12:22:56 -0700 Received: from kakulavarapu.capsl.udel.edu (kakulavarapu.capsl.udel.edu [128.4.10.48]) by olsen.capsl.udel.edu (8.9.1/8.9.1) with SMTP id PAA21906 for ; Wed, 2 May 2001 15:22:54 -0400 (EDT) Date: Wed, 2 May 2001 15:22:53 -0400 (EDT) From: Hongbo Yang To: pro64-support@oss.sgi.com Subject: variants.h : integer constant out of range Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pro64-support@oss.sgi.com Precedence: bulk In variants.h, there is a macro definition: #define V_PF_FLAGS 0xffffffff00000000 /* Prefetch flags */ While compiling the programs that use this macro using GCC 2.95.3 it always complains that "integer constant out of range". -- Hongbo Yang From owner-pro64-support@oss.sgi.com Wed May 2 12:35:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f42JZZF04017 for pro64-support-outgoing; Wed, 2 May 2001 12:35:35 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42JZXF04002 for ; Wed, 2 May 2001 12:35:33 -0700 Received: from sgihud.hudson.sgi.com (sgihud.hudson.sgi.com [169.238.41.4]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id VAA591351 for ; Wed, 2 May 2001 21:35:30 +0200 (CEST) mail_from (lesniak@sgihud.hudson.sgi.com) Received: (from lesniak@localhost) by sgihud.hudson.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id PAA05069; Wed, 2 May 2001 15:34:13 -0400 (EDT) Date: Wed, 2 May 2001 15:34:13 -0400 (EDT) From: lesniak@sgihud.hudson.sgi.com (Ken Lesniak) Message-Id: <200105021934.PAA05069@sgihud.hudson.sgi.com> To: pro64-support@oss.sgi.com, Hongbo Yang Subject: Re: variants.h : integer constant out of range Reply-To: lesniak@sgihud.hudson.sgi.com Sender: owner-pro64-support@oss.sgi.com Precedence: bulk >In variants.h, there is a macro definition: > >#define V_PF_FLAGS 0xffffffff00000000 /* Prefetch flags */ > >While compiling the programs that use this macro using GCC 2.95.3 it >always complains that "integer constant out of range". > >-- Hongbo Yang I must have a different version of gcc. Or maybe my eyes are worse than I thought. I'll fix it. The constant should have a 'ULL' suffix. Thanks... Ken From owner-pro64-support@oss.sgi.com Wed May 2 12:39:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f42JdUe05759 for pro64-support-outgoing; Wed, 2 May 2001 12:39:30 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42JdRF05730 for ; Wed, 2 May 2001 12:39:27 -0700 Received: from gaea.engr.sgi.com (gaea.engr.sgi.com [130.62.180.97]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id VAA597861 for ; Wed, 2 May 2001 21:39:25 +0200 (CEST) mail_from (murthy@sgi.com) Received: from sgi.com (localhost [127.0.0.1]) by gaea.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id MAA67063; Wed, 2 May 2001 12:36:21 -0700 (PDT) Message-ID: <3AF061B5.6B6C7BCB@sgi.com> Date: Wed, 02 May 2001 12:36:21 -0700 From: Chandrasekhar Murthy X-Mailer: Mozilla 4.51C-SGI [en] (X11; I; IRIX 6.5 IP32) X-Accept-Language: en MIME-Version: 1.0 To: Hongbo Yang CC: pro64-support@oss.sgi.com Subject: Re: variants.h : integer constant out of range References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Hongbo Yang wrote: > > In variants.h, there is a macro definition: > > #define V_PF_FLAGS 0xffffffff00000000 /* Prefetch flags */ > > While compiling the programs that use this macro using GCC 2.95.3 it > always complains that "integer constant out of range". > > -- Hongbo Yang I think changing the define to #define V_PF_FLAGS 0xffffffff00000000LL /* Prefetch flags */ should fix the problem. Murthy From owner-pro64-support@oss.sgi.com Wed May 2 13:39:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f42KdRT25991 for pro64-support-outgoing; Wed, 2 May 2001 13:39:27 -0700 Received: from ganymede.or.intel.com (jffdns01.or.intel.com [134.134.248.3]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42KdMF25963 for ; Wed, 2 May 2001 13:39:22 -0700 Received: from SMTP (orsmsxvs02-1.jf.intel.com [192.168.65.201]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.36 2001/04/18 16:16:02 root Exp $) with SMTP id UAA19254 for ; Wed, 2 May 2001 20:39:17 GMT Received: from orsmsx29.jf.intel.com ([192.168.70.29]) by 192.168.70.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 02 May 2001 20:39:17 0000 (GMT) Received: by orsmsx29.jf.intel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 2 May 2001 13:39:15 -0700 Message-ID: From: "Kakulavarapu, Prasad" To: pro64-support@oss.sgi.com Subject: Reloaction truncation Error at Link time Date: Wed, 2 May 2001 13:03:33 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Hello, This is probably an old issue; I see a relocation truncation error at link time with sgicc. I am running Pro64 compielrs on the Linux64 (in IA-32 binary compatibility mode). SGIcc Compilers: Version 0.01.0-12 Linux lion64 2.4.0test10-001115-58smp #1 SMP Wed Dec 20 14:11:57 PST 2000 ia64 unknown I know these are not the latest configs, but I remember the --relax bug was fixed with pro64 Version 10. sgicc -I. -o run meas.o qtmdb.o libstp.a libqt.a --- --- meas.o: In function `test02': meas.o(.text+0xb92): relocation truncated to fit: PCREL21B qt_blocki meas.o(.text+0xc12): relocation truncated to fit: PCREL21B qt_blocki meas.o(.text+0xc92): relocation truncated to fit: PCREL21B qt_blocki meas.o(.text+0xd12): relocation truncated to fit: PCREL21B qt_blocki meas.o(.text+0xd92): relocation truncated to fit: PCREL21B qt_blocki --- I used the relax option; sgicc -I. -o run --relax meas.o qtmdb.o libstp.a libqt.a sgicc ERROR: -- not allowed in non XPG4 environment sgicc ERROR parsing --relax: unknown flag Any help apprecaited. Thanks, Prasad From owner-pro64-support@oss.sgi.com Wed May 2 13:54:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f42Ks1H31351 for pro64-support-outgoing; Wed, 2 May 2001 13:54:01 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42Ks0F31347 for ; Wed, 2 May 2001 13:54:01 -0700 Received: from gaea.engr.sgi.com (gaea.engr.sgi.com [130.62.180.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id OAA09090 for ; Wed, 2 May 2001 14:04:43 -0700 (PDT) mail_from (murthy@gaea.engr.sgi.com) Received: (from murthy@localhost) by gaea.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id NAA49196; Wed, 2 May 2001 13:51:16 -0700 (PDT) Date: Wed, 2 May 2001 13:51:16 -0700 (PDT) From: murthy@gaea.engr.sgi.com (Chandrasekhar Murthy) Message-Id: <200105022051.NAA49196@gaea.engr.sgi.com> To: pro64-support@oss.sgi.com, "Kakulavarapu, Prasad" Subject: Re: Reloaction truncation Error at Link time Sender: owner-pro64-support@oss.sgi.com Precedence: bulk You could try -Wl,-relax. Murthy From owner-pro64-support@oss.sgi.com Wed May 2 13:56:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f42KuYx00345 for pro64-support-outgoing; Wed, 2 May 2001 13:56:34 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42KuXF00336 for ; Wed, 2 May 2001 13:56:33 -0700 Received: from rohi.engr.sgi.com ([130.62.180.74]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id NAA08814 for ; Wed, 2 May 2001 13:56:30 -0700 (PDT) mail_from (mpm@rohi.engr.sgi.com) Received: (from mpm@localhost) by rohi.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id NAA38286; Wed, 2 May 2001 13:52:37 -0700 (PDT) Date: Wed, 2 May 2001 13:52:37 -0700 (PDT) From: mpm@rohi.engr.sgi.com (Michael Murphy) Message-Id: <200105022052.NAA38286@rohi.engr.sgi.com> To: pro64-support@oss.sgi.com, "Kakulavarapu, Prasad" Subject: Re: Reloaction truncation Error at Link time Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Try sgicc -Wl,--relax -- Mike Murphy -- mpm@sgi.com -- quote of the day: -- "Conscience is the email your head gets from heaven." (Bil Keane) From owner-pro64-support@oss.sgi.com Wed May 2 14:02:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f42L29Q02603 for pro64-support-outgoing; Wed, 2 May 2001 14:02:09 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42L26F02586 for ; Wed, 2 May 2001 14:02:06 -0700 Received: from rohi.engr.sgi.com (rohi.engr.sgi.com [130.62.180.74]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id XAA616307 for ; Wed, 2 May 2001 23:02:04 +0200 (CEST) mail_from (mpm@rohi.engr.sgi.com) Received: (from mpm@localhost) by rohi.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id NAA38089; Wed, 2 May 2001 13:58:00 -0700 (PDT) Date: Wed, 2 May 2001 13:58:00 -0700 (PDT) From: mpm@rohi.engr.sgi.com (Michael Murphy) Message-Id: <200105022058.NAA38089@rohi.engr.sgi.com> To: Pro64 Support , Stephen Pickles Subject: Re: sgif90 -listing Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Yes, this is a problem. I'll file a bug with the appropriate people. Thanks for pointing this out. -- Mike Murphy -- mpm@sgi.com -- quote of the day: -- "Conscience is the email your head gets from heaven." (Bil Keane) From owner-pro64-support@oss.sgi.com Wed May 2 17:47:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f430lac17479 for pro64-support-outgoing; Wed, 2 May 2001 17:47:36 -0700 Received: from ganymede.or.intel.com (jffdns01.or.intel.com [134.134.248.3]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f430lZF17476 for ; Wed, 2 May 2001 17:47:35 -0700 Received: from SMTP (orsmsxvs02-1.jf.intel.com [192.168.65.201]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.36 2001/04/18 16:16:02 root Exp $) with SMTP id AAA19549; Thu, 3 May 2001 00:47:19 GMT Received: from orsmsx29.jf.intel.com ([192.168.70.29]) by 192.168.70.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 03 May 2001 00:47:18 0000 (GMT) Received: by orsmsx29.jf.intel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 2 May 2001 17:47:17 -0700 Message-ID: From: "Kakulavarapu, Prasad" To: "'mpm@rohi.engr.sgi.com'" , pro64-support@oss.sgi.com, "Kakulavarapu, Prasad" Subject: RE: Reloaction truncation Error at Link time Date: Wed, 2 May 2001 16:38:56 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Thanks to everyone. That worked. --Prasad > -----Original Message----- > From: mpm@rohi.engr.sgi.com [SMTP:mpm@rohi.engr.sgi.com] > Sent: Wednesday, May 02, 2001 1:53 PM > To: pro64-support@oss.sgi.com; Kakulavarapu, Prasad > Subject: Re: Reloaction truncation Error at Link time > > Try sgicc -Wl,--relax > -- Mike Murphy > -- mpm@sgi.com > -- quote of the day: > -- "Conscience is the email your head gets from heaven." (Bil Keane) From owner-pro64-support@oss.sgi.com Wed May 2 17:52:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f430q8l17673 for pro64-support-outgoing; Wed, 2 May 2001 17:52:08 -0700 Received: from scapa.cs.ualberta.ca (root@scapa.cs.ualberta.ca [129.128.4.44]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f430q8F17670 for ; Wed, 2 May 2001 17:52:08 -0700 Received: (from localhost user: 'pengzhao' uid#483 fake: STDIN (pengzhao@peers)) by scapa.cs.ualberta.ca id ; Wed, 2 May 2001 18:51:52 -0600 Date: Wed, 2 May 2001 18:51:51 -0600 (MDT) From: Peng Zhao To: sgi Subject: A queston on preamble. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Hi, It has been a long time since I noticed the whirl tree dumped. There are usually two "blank" block at the beginning of a function. Like: FUNC_ENTRY BODY BLOCK END_BLOCK BLOCK END_BLOCK PRAGMA 0 120 0 (0x0) #PREAMBLE_END What is the function of the two blank blocks and the concept of preamble? Thanks. -- Regards Peng Peng Zhao pengzhao@cs.ualberta.ca http://www.cs.ualberta.ca/~pengzhao TEL (Lab): (780)492-3725 Lab: CSC251 From owner-pro64-support@oss.sgi.com Thu May 3 04:24:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f43BOK912293 for pro64-support-outgoing; Thu, 3 May 2001 04:24:20 -0700 Received: from narkis.wisdom.weizmann.ac.il (narkis.wisdom.weizmann.ac.il [132.76.80.32]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43BOIF12287 for ; Thu, 3 May 2001 04:24:18 -0700 Received: from wisdom.weizmann.ac.il (amir8-pc.wisdom.weizmann.ac.il [132.76.81.32]) by narkis.wisdom.weizmann.ac.il (8.9.3/8.9.3) with ESMTP id OAA05160 for ; Thu, 3 May 2001 14:22:52 +0300 (IDT) Message-ID: <3AF14DC9.F354901B@wisdom.weizmann.ac.il> Date: Thu, 03 May 2001 14:23:38 +0200 From: raya Organization: Weizmann Institute of Science X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: il,en MIME-Version: 1.0 To: pro64 Subject: loopunrolling & swp Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Hello, Is it possible to disable loop unrolling but allows software pipelineing ? Is the opposite also possible ? How can I do it? Brst Regards, -- Raya Leviathan Tel. 972-8-9344208 (office) Tel. 972-3-6358481 (home) Email: raya@wisdom.weizmann.ac.il From owner-pro64-support@oss.sgi.com Thu May 3 07:19:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f43EJCx07991 for pro64-support-outgoing; Thu, 3 May 2001 07:19:12 -0700 Received: from olsen.capsl.udel.edu (olsen.capsl.udel.edu [128.4.10.3]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43EJBF07982 for ; Thu, 3 May 2001 07:19:11 -0700 Received: from kakulavarapu.capsl.udel.edu (kakulavarapu.capsl.udel.edu [128.4.10.48]) by olsen.capsl.udel.edu (8.9.1/8.9.1) with SMTP id KAA04806; Thu, 3 May 2001 10:19:06 -0400 (EDT) Date: Thu, 3 May 2001 10:19:06 -0400 (EDT) From: Hongbo Yang To: raya cc: pro64 Subject: Re: loopunrolling & swp In-Reply-To: <3AF14DC9.F354901B@wisdom.weizmann.ac.il> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Just like an old Chinese saying "Heroes Share the Common View on the World". Also I am interested in investigating the optimization effect of loop unrolling and swp individually. Modify the function void CG_LOOP::Determine_SWP_Unroll_Factor() by adding a statement at the end: Set_unroll_factor(1); will work. -------------------------------- Hongbo Yang Electrical Engineering Univ of Delaware From owner-pro64-support@oss.sgi.com Thu May 3 08:04:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f43F41W25650 for pro64-support-outgoing; Thu, 3 May 2001 08:04:01 -0700 Received: from mail-in.hq.tensilica.com (hq.tensilica.com [38.170.141.29]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43F3lF25546 for ; Thu, 3 May 2001 08:03:50 -0700 Received: from tensilica.com ([192.168.16.250]) by mail-in.hq.tensilica.com (8.9.3/8.9.3) with ESMTP id IAA19628; Thu, 3 May 2001 08:03:00 -0700 Message-ID: <3AF1731C.3A1FAF79@tensilica.com> Date: Thu, 03 May 2001 08:02:52 -0700 From: Nenad Nedeljkovic X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: raya CC: pro64 Subject: Re: loopunrolling & swp References: <3AF14DC9.F354901B@wisdom.weizmann.ac.il> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pro64-support@oss.sgi.com Precedence: bulk > Is it possible to disable loop unrolling but allows software pipelineing ? -SWP:max_unroll_times=1 > Is the opposite also possible ? Try -SWP:prep_only Nenad From owner-pro64-support@oss.sgi.com Thu May 3 09:58:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f43GwVM07618 for pro64-support-outgoing; Thu, 3 May 2001 09:58:31 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43GwSF07615 for ; Thu, 3 May 2001 09:58:28 -0700 Received: from gaea.engr.sgi.com (gaea.engr.sgi.com [130.62.180.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id JAA28679 for ; Thu, 3 May 2001 09:57:07 -0700 (PDT) mail_from (murthy@sgi.com) Received: from sgi.com (localhost [127.0.0.1]) by gaea.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id JAA57185; Thu, 3 May 2001 09:55:06 -0700 (PDT) Message-ID: <3AF18D69.74EAD7CC@sgi.com> Date: Thu, 03 May 2001 09:55:05 -0700 From: Chandrasekhar Murthy X-Mailer: Mozilla 4.51C-SGI [en] (X11; I; IRIX 6.5 IP32) X-Accept-Language: en MIME-Version: 1.0 To: Peng Zhao CC: sgi Subject: Re: A queston on preamble. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Peng Zhao wrote: > > Hi, > > It has been a long time since I noticed the whirl tree dumped. > > There are usually two "blank" block at the beginning of a function. Like: > > FUNC_ENTRY > BODY > BLOCK > END_BLOCK > BLOCK > END_BLOCK > PRAGMA 0 120 0 (0x0) #PREAMBLE_END > > What is the function of the two blank blocks and the concept of > preamble? Thanks. > The WHIRL document description for FUNC_ENTRY gives the description of the two blocks (both are related to pragma information). If my memory serves me right, the information before the preamble in the function body contains information such as the saving of the array bounds on entry for adjustable arrays and some other information. I think this was done mostly for LNO. > -- > Regards > > Peng > Peng Zhao pengzhao@cs.ualberta.ca > http://www.cs.ualberta.ca/~pengzhao > TEL (Lab): (780)492-3725 Lab: CSC251 From owner-pro64-support@oss.sgi.com Thu May 3 11:28:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f43ISKK12761 for pro64-support-outgoing; Thu, 3 May 2001 11:28:20 -0700 Received: from olsen.capsl.udel.edu (olsen.capsl.udel.edu [128.4.10.3]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43ISKF12757 for ; Thu, 3 May 2001 11:28:20 -0700 Received: from kakulavarapu.capsl.udel.edu (kakulavarapu.capsl.udel.edu [128.4.10.48]) by olsen.capsl.udel.edu (8.9.1/8.9.1) with SMTP id OAA07611; Thu, 3 May 2001 14:28:13 -0400 (EDT) Date: Thu, 3 May 2001 14:28:13 -0400 (EDT) From: Hongbo Yang To: Nenad Nedeljkovic cc: raya , pro64 Subject: Re: loopunrolling & swp In-Reply-To: <3AF1731C.3A1FAF79@tensilica.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pro64-support@oss.sgi.com Precedence: bulk On Thu, 3 May 2001, Nenad Nedeljkovic wrote: > > Is it possible to disable loop unrolling but allows software pipelineing ? > > -SWP:max_unroll_times=1 > > > Is the opposite also possible ? > > Try -SWP:prep_only Or use -SWP:=false to disable SWP? -- Yang From owner-pro64-support@oss.sgi.com Thu May 3 15:01:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f43M1Uw17810 for pro64-support-outgoing; Thu, 3 May 2001 15:01:30 -0700 Received: from escelsa.com.br (smtp.escelsanet.com.br [200.242.30.218]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f43M1SF17807 for ; Thu, 3 May 2001 15:01:29 -0700 Received: from blackbird.conexo.com.br ([200.242.14.104]) by escelsa.com.br ; Thu, 03 May 2001 19:00:59 -0300 From: Sandro Camata To: pro64-support@oss.sgi.com Subject: Problems compiling spec95 Date: Thu, 3 May 2001 19:01:59 -0300 X-Mailer: KMail [version 1.0.29] Content-Type: text/plain MIME-Version: 1.0 Message-Id: <01050319033600.07120@blackbird.conexo.com.br> Content-Transfer-Encoding: 8bit Sender: owner-pro64-support@oss.sgi.com Precedence: bulk There is some especial configuration for vortex and jpeg to make it compile and run successfully? I'm having problems running jpeg when compiled with -O0. -O1 and -O2 works fine. Vortex doesn't compile. I'm using nue version 1.0-1 and PRO64 version 0.01.0-12.ia64 thanks Sandro Camata camata@computer.org ------------------------------------------------------- From owner-pro64-support@oss.sgi.com Fri May 4 06:08:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f44D8l609432 for pro64-support-outgoing; Fri, 4 May 2001 06:08:47 -0700 Received: from sunshine.math.utah.edu (IDENT:HylO78sc7vyVLXXrkCB0eSHp4VMP3iN0@sunshine.math.utah.edu [128.110.198.2]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f44D8SF09424 for ; Fri, 4 May 2001 06:08:28 -0700 Received: from suncore.math.utah.edu (IDENT:IMX5RBfVdyH7uvqto4mi6sKGtP1QOSZr@suncore0.math.utah.edu [128.110.198.5]) by sunshine.math.utah.edu (8.9.3/8.9.3) with ESMTP id HAA18713; Fri, 4 May 2001 07:07:59 -0600 (MDT) Received: (from beebe@localhost) by suncore.math.utah.edu (8.9.3/8.9.3) id HAA05209; Fri, 4 May 2001 07:07:57 -0600 (MDT) Date: Fri, 4 May 2001 07:07:57 -0600 (MDT) From: "Nelson H. F. Beebe" To: pro64-support@oss.sgi.com Cc: beebe@math.utah.edu, Sandro Camata X-US-Mail: "Center for Scientific Computing, Department of Mathematics, 322 INSCC, University of Utah, 155 S 1400 E RM 233, Salt Lake City, UT 84112-0090, USA" X-Telephone: +1 801 581 5254 X-FAX: +1 801 585 1640, +1 801 581 4148 X-URL: http://www.math.utah.edu/~beebe Subject: Re: Problems compiling spec95 Message-ID: Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Sandro Camata writes on Thu, 3 May 2001 19:01:59 -0300: >> I'm having problems running jpeg when compiled with -O0. -O1 and -O2 works fine. >> ... I'm using nue version 1.0-1 and PRO64 version 0.01.0-12.ia64 I just built the jpeg-6b distribution like this: env CC=sgicc ./configure && make all check I have version 0.01.0-13 of sgicc, and the tests all passed with the default -O2. I then did make clean make CFLAGS='-O0 -I$(srcdir)' all check The tests all passed. I appears that my later version of sgicc has fixed the problems Sandro reported. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - Center for Scientific Computing FAX: +1 801 585 1640, +1 801 581 4148 - - University of Utah Internet e-mail: beebe@math.utah.edu - - Department of Mathematics, 322 INSCC beebe@acm.org beebe@computer.org - - 155 S 1400 E RM 233 beebe@ieee.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe - ------------------------------------------------------------------------------- From owner-pro64-support@oss.sgi.com Fri May 4 14:32:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f44LWe525482 for pro64-support-outgoing; Fri, 4 May 2001 14:32:40 -0700 Received: from lochinvar.ece.neu.edu (mail2.ece.neu.edu [129.10.60.82]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f44LWYF25479 for ; Fri, 4 May 2001 14:32:34 -0700 Received: from coruscant.ece.neu.edu (coruscant.ece.neu.edu [129.10.60.242]) by lochinvar.ece.neu.edu (8.9.3/8.9.3) with ESMTP id RAA12385 for ; Fri, 4 May 2001 17:33:22 -0400 (EDT) Received: from localhost by coruscant.ece.neu.edu (8.9.3/8.9.3) with ESMTP id RAA07000 for ; Fri, 4 May 2001 17:32:25 -0400 (EDT) Date: Fri, 4 May 2001 17:32:25 -0400 (EDT) From: Elias Mizan To: pro64-support@oss.sgi.com Subject: Instruction Group / Bundle formation Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Could you tell me in which files of the Code Generator are the instruction groups and bundles formed for IA64 ? Regards, Elias From owner-pro64-support@oss.sgi.com Fri May 4 14:40:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f44LeTH25697 for pro64-support-outgoing; Fri, 4 May 2001 14:40:29 -0700 Received: from hypnos.cps.intel.com (hypnos.cps.intel.com [192.198.165.17]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f44LeSF25694 for ; Fri, 4 May 2001 14:40:28 -0700 Received: from SMTP (fmsmsxvs03-1.fm.intel.com [132.233.42.203]) by hypnos.cps.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.36 2001/04/18 16:16:02 root Exp $) with SMTP id VAA20527; Fri, 4 May 2001 21:39:05 GMT Received: from fmsmsx19.fm.intel.com ([132.233.48.19]) by 132.233.48.203 (Norton AntiVirus for Internet Email Gateways 1.0) ; Fri, 04 May 2001 21:39:04 0000 (GMT) Received: by fmsmsx19.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 4 May 2001 14:39:02 -0700 Message-ID: <9287DC1579B0D411AA2F009027F44C3F042DFA7E@FMSMSX41> From: "Chan, Sun C" To: "'Elias Mizan'" , pro64-support@oss.sgi.com Subject: RE: Instruction Group / Bundle formation Date: Fri, 4 May 2001 14:38:51 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-pro64-support@oss.sgi.com Precedence: bulk cgemit.cxx, ia64/cgtarget.cxx a lot of the instruction info is in targinfo which are a bunch of tables build offline. Sun > -----Original Message----- > From: Elias Mizan [mailto:emizan@ECE.NEU.EDU] > Sent: Friday, May 04, 2001 2:32 PM > To: pro64-support@oss.sgi.com > Subject: Instruction Group / Bundle formation > > > > Could you tell me in which files of the Code Generator are > the instruction > groups and bundles formed for IA64 ? > > Regards, > > Elias > > > From owner-pro64-support@oss.sgi.com Fri May 4 14:55:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f44LteZ26375 for pro64-support-outgoing; Fri, 4 May 2001 14:55:40 -0700 Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f44LtdF26372 for ; Fri, 4 May 2001 14:55:39 -0700 Received: from SMTP (fmsmsxvs01-1.fm.intel.com [132.233.42.201]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.36 2001/04/18 16:16:02 root Exp $) with SMTP id VAA23201 for ; Fri, 4 May 2001 21:55:29 GMT Received: from fmsmsx27.FM.INTEL.COM ([132.233.48.27]) by 132.233.48.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Fri, 04 May 2001 21:55:29 0000 (GMT) Received: by fmsmsx27.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 4 May 2001 14:55:26 -0700 Message-ID: <9287DC1579B0D411AA2F009027F44C3F042DFA7F@FMSMSX41> From: "Chan, Sun C" To: pro64-support@oss.sgi.com Subject: On how to use mempool Date: Fri, 4 May 2001 14:54:09 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-pro64-support@oss.sgi.com Precedence: bulk As more and more diverse groups try to add different optimizations to Pro64, one important aspect has not been talked about is how memory should be handled. I've had some discussion with Raymond Lo and Wilson Ho a couple of months ago. The following are notes I've taken that gives our own conclusion on how to get memory (in place of calling malloc and friends directly). In case you don't know, in Pro64, the preferred method to get memory is through MEMPOOLS. This write up is to fill in some gap for new writers to Pro64. The notes are taken w.r.t. MEMPOOL usage in cg. But the same really holds true for all backend phases (namely, IPA, LNO, WOPT and CG) The following are ways to handle mempool in CG. 1. The old C style way MEM_POOL_Push(&MEM_local_pool); MEM_POOL_Push(&MEM_local_nz_pool); the two different pools are passed to relevant routines that needs memory, later on, used like the following: loop_set = BB_SET_Create_Empty(PU_BB_Count + 2, pool); where pool is the parameter with actual being &MEM_local_pool There needs to be a finalize routine that pops the mempools. 2. a little newer way, for local temp memory, this method can simply use alloca e.g. Local_Insn_Sched (void) { for (bb = REGION_First_BB; bb != NULL; bb = BB_next(bb)) { if (bb->Spilled() || !bb->Scheduled()) { MEM_POOL_Push(&MEM_local_pool); sched = CXX_NEW(LOCAL_SCHEDULER(bb), &MEM_local_pool); sched->Schedule(); CXX_DELETE(sched, &MEM_local_pool); MEM_POOL_Pop(&MEM_local_pool); } } } 3. a more sophistical way that works in cg phase also, I am taking the fb_cfg.h and fg_cfg.cxx as example. I've enclosed the source as attachment. essentially, a class class FB_CFG_MEM { protected: MEM_POOL _m; FB_CFG_MEM() { MEM_POOL_Initialize( &_m, "FB_CFG_MEM", true); MEM_POOL_Push( &_m ); } ~FB_CFG_MEM() { MEM_POOL_Pop( &_m ); MEM_POOL_Delete( &_m ); } }; FB_CFG: public FB_CFG_MEM { ... hashmap< LABEL_IDX, FB_NODEX, hash, equal_to, mempool_allocator< pair > > _lblx_to_nx; deque< FB_EDGE_DELAYED, mempool_allocator > _delayed_edges; FB_NODEX _curr_nx; ... }; The FB_CFG graph is implemented as a deque of nodes and edges. Here, no mempool operation is exposed in the routines such as FB_CFG::New_Node, Add_edge. The constructors for the containers _nodes, _lblx_to_nx and _delayed_edges are explicitly called from the constructor of FB_CFG and the mempool _m is passed down there, making sure mempool is properly initialized, stacked and deleted upon exit. We all agreed the method #1 is NOT desirable since there hides an assumed method of push and pop with a initialize routine and finalize routine, but no way to enforce implementors to do that in the right sequence. Currently, CG uses #1 or #2. The problem with #2 is (according to Raymond): when you "break" out of loop or "return" from a procedure, you have to insert MEM_POOL_pop at each exit paths. And I usually don't get it correct the first time, or forget to add the necessary insert when I fix bugs (the MEM_POOL_Push is too far up in the procedure!). For #3, let me do more explanation: If you look at CXX_MEM_POOL, it does the same thing as FB_CFG_MEM. So class FB_CFG could have been declared as class FB_CFG : public CXX_MEM_POOL {...}; Memory used by the containers (i.e., the deque and hashmap here) is released by the containers themselves. In this example, it simply tells the containers to use the specified mempool as memory allocator. Any object created by these containers will accquire memory from this mempool. And the memory will be released back to the mempool when these objects' destructors are called. According to Wilson: There were two reasons to implement (3). First, that's the standard way to integrate a user-defined memory allocation scheme with STL. You can't use mempool with STL if you stay with (1) or (2). Second, even if you are not using STL, wrapping the mempool in a class is better because it guarantees that each mempool is properly deallocated at the right scope. Some minor comments from Raymond on the side: Just a personal style, I never use MEM_POOL_Push (except to initialize a MEMPOOL). I always create a new MEMPOOL, since there is no reason to reuse of MEMPOOL for different things. That's enforced by (3) On a different issue, I prefer not to use MEMPOOL with STL, since it makes the STL constructor very ugly. I am not convinced that MEMPOOL is any better than malloc in the case of STL, if it is not worse. For example, STL vector already does bulk allocation. MEMPOOL might speed up STL linked list, but who is using linked list. The advantage of malloc is that memory is immediately returned and there is not much overheads. The disadvantage of MEMPOOL is that it allocates in chunks of 4K or more and is very inefficient for small data structures. Hope this will give you enough input to talk about mempool. Also, I suppose that's the reason it was suggested that for really temporary memory pool usage that stays locally in the same routines, one should also consider using alloca, it is a good compromise to avoid unnecessary overhead of memory allocation. On the other hand, this usage should rarely be needed. Note that so far, we've recommended using #3 method to allocate memory. This is using in conjunction with STL. For people new to or not familiar with STL or for whatever reason don't want to use STL container classes, The following usage is also possible: in cg_swp.cxx CXX_MEM_POOL swp_local_pool(...); SWP_OP_vector swp_op_vector(..., swp_local_pool()); ... no cxx_new is needed, nor do you do push and pop. It is taken care of through the constructor/destructor. This usage is a simply variation of #3. Why not use this method as the recommended? STL provides a lot of data structures and access routines, there's really no need to write your own linked list, hash, vector etc. The example cited is because it wants to use SWP_OP_vector which is an old data structure before STL is part of ANSI standard. I would say, the guideline is if you have to used existing data structure that is not STL, use this method. From owner-pro64-support@oss.sgi.com Sun May 6 10:35:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f46HZI808339 for pro64-support-outgoing; Sun, 6 May 2001 10:35:18 -0700 Received: from scapa.cs.ualberta.ca (root@scapa.cs.ualberta.ca [129.128.4.44]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f46HZEF08335 for ; Sun, 6 May 2001 10:35:18 -0700 Received: (from localhost user: 'pengzhao' uid#483 fake: STDIN (pengzhao@peers)) by scapa.cs.ualberta.ca id ; Sun, 6 May 2001 11:34:53 -0600 Date: Sun, 6 May 2001 11:34:53 -0600 (MDT) From: Peng Zhao To: sgi Subject: "paths" problem in pro64 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Hi, How to tell the sgicc where it should search for the executable it invokes(such as ipa_link, inline etc)? everytime, sgicc tries to invoke "/usr/lib/gcc-lib/ia64-sgi-linux/sgicc-1.0/ipa_link", but ipa_link is not there, it is in a non-classical directory I maked. And is there any neat solution to avoid "undefined reference to `__profile_pu_init'" error when using special libraries? Following are the tries I made: Can somebody explain me the related environment varialbes? ------------------- NUE>sgicc -fb_create ./test test.c -o test test.o:/usr/sakwatamau/brule12/grad/pengzhao/test/test.c:4: undefined reference to `__profile_init' test.o: In function `main': test.o(.text+0x72): undefined reference to `__profile_pu_init' test.o(.text+0x92): undefined reference to `__profile_invoke_init' test.o(.text+0xb2): undefined reference to `__profile_branch_init' test.o(.text+0xd2): undefined reference to `__profile_call_init' test.o(.text+0xf2): undefined reference to `__profile_invoke' test.o(.text+0x162): undefined reference to `__profile_branch' test.o(.text+0x1b2): undefined reference to `__profile_call_entry' test.o(.text+0x212): undefined reference to `__profile_call_exit' test.o(.text+0x252): undefined reference to `__profile_call_entry' test.o(.text+0x2b2): undefined reference to `__profile_call_exit' collect2: ld returned 1 exit status NUE:/usr/brule12/grad/pengzhao/test> ----------------------- NUE>sgicc -fb_create ./test test.c -o test -linstr /usr/lib/gcc-lib/ia64-hp-linux/2.9-ia64-000216/../../../../ia64-hp-linux/bin/ld: cannot find -linstr collect2: ld returned 1 exit status ------------------------ Thank you. From owner-pro64-support@oss.sgi.com Sun May 6 12:13:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f46JDSA10164 for pro64-support-outgoing; Sun, 6 May 2001 12:13:28 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f46JDRF10161 for ; Sun, 6 May 2001 12:13:27 -0700 Received: from cchkms.engr.sgi.com ([130.62.180.48]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA05915 for ; Sun, 6 May 2001 12:13:26 -0700 (PDT) mail_from (rat@cchkms.engr.sgi.com) Received: (from rat@localhost) by cchkms.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id MAA02394; Sun, 6 May 2001 12:09:14 -0700 (PDT) Date: Sun, 6 May 2001 12:09:14 -0700 (PDT) From: rat@cchkms.engr.sgi.com (Ross A. Towle) Message-Id: <200105061909.MAA02394@cchkms.engr.sgi.com> To: sgi , Peng Zhao Subject: Re: "paths" problem in pro64 Sender: owner-pro64-support@oss.sgi.com Precedence: bulk The flag -Yx, where x is the phase letter and is the directory pathname allows you to pick up alternate copies of the phases. -Ross From owner-pro64-support@oss.sgi.com Sun May 6 13:24:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f46KOmN12234 for pro64-support-outgoing; Sun, 6 May 2001 13:24:48 -0700 Received: from scapa.cs.ualberta.ca (root@scapa.cs.ualberta.ca [129.128.4.44]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f46KOlF12231 for ; Sun, 6 May 2001 13:24:47 -0700 Received: (from localhost user: 'pengzhao' uid#483 fake: STDIN (pengzhao@peers)) by scapa.cs.ualberta.ca id ; Sun, 6 May 2001 14:24:29 -0600 Date: Sun, 6 May 2001 14:24:29 -0600 (MDT) From: Peng Zhao To: "Ross A. Towle" cc: sgi Subject: Re: "paths" problem in pro64 In-Reply-To: <200105061909.MAA02394@cchkms.engr.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Thanks. Is there any environment variables do the job? the command line is long and ugly with so many -Y options. I use the NUE to generate the libraries and compile a simple program. It seems it can generate a executable. but when I run the a.out, it gives some error message that seems to be a problem about path, the output is like this way: NUE>a.out /lib/ld-linux-ia64.so.2 - No such file or directory bski: Could not open a.out for reading I guess it is not the problem mentioned by SGI (e.g.must use a libc2.2 based NUE) and how to set the path sgicc through which find the intended library(e.g. libinstr.a)? Thanks. On Sun, 6 May 2001, Ross A. Towle wrote: > The flag -Yx, where x is the phase letter and is the > directory pathname allows you to pick up alternate copies of the phases. > > -Ross > -- Regards Peng Peng Zhao pengzhao@cs.ualberta.ca http://www.cs.ualberta.ca/~pengzhao TEL (Lab): (780)492-3725 Lab: CSC251 From owner-pro64-support@oss.sgi.com Sun May 6 13:30:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f46KUAL12400 for pro64-support-outgoing; Sun, 6 May 2001 13:30:10 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f46KU9F12397 for ; Sun, 6 May 2001 13:30:09 -0700 Received: from dsl-proof.corp.sgi.com ([192.102.142.250]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id NAA05201 for ; Sun, 6 May 2001 13:30:08 -0700 (PDT) mail_from (dlstephe@sgi.com) Received: from sgi.com (localhost [127.0.0.1]) by dsl-proof.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id NAA98612; Sun, 6 May 2001 13:26:11 -0700 (PDT) Message-ID: <3AF5B363.65EE8D75@sgi.com> Date: Sun, 06 May 2001 13:26:11 -0700 From: David Stephenson Organization: SGI -- Compilers X-Mailer: Mozilla 4.7C-SGI [en] (X11; I; IRIX 6.5 IP32) X-Accept-Language: en MIME-Version: 1.0 To: Peng Zhao CC: sgi Subject: Re: "paths" problem in pro64 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Peng Zhao wrote: > And is there any neat solution to avoid > "undefined reference to `__profile_pu_init'" error when using > special libraries? Following are the tries I made: Can somebody explain > me the related environment varialbes? > > ------------------- > > NUE>sgicc -fb_create ./test test.c -o test > test.o:/usr/sakwatamau/brule12/grad/pengzhao/test/test.c:4: undefined > reference to `__profile_init' test.o: In function `main': > test.o(.text+0x72): undefined reference to `__profile_pu_init' > test.o(.text+0x92): undefined reference to `__profile_invoke_init' > test.o(.text+0xb2): undefined reference to `__profile_branch_init' > test.o(.text+0xd2): undefined reference to `__profile_call_init' > test.o(.text+0xf2): undefined reference to `__profile_invoke' > test.o(.text+0x162): undefined reference to `__profile_branch' > test.o(.text+0x1b2): undefined reference to `__profile_call_entry' > test.o(.text+0x212): undefined reference to `__profile_call_exit' > test.o(.text+0x252): undefined reference to `__profile_call_entry' > test.o(.text+0x2b2): undefined reference to `__profile_call_exit' > collect2: ld returned 1 exit status NUE:/usr/brule12/grad/pengzhao/test> > ----------------------- > NUE>sgicc -fb_create ./test test.c -o test -linstr > /usr/lib/gcc-lib/ia64-hp-linux/2.9-ia64-000216/../../../../ia64-hp-linux/bin/ld: > cannot find -linstr collect2: ld returned 1 exit status > ------------------------ __profile_init and the other undefined names are the names of procedures in the libiinstr.so library used during instrumentation. During compilation with instrumentation, calls to these procedures are inserted into the WHIRL code of the program being compiled. When the instrumented binary is run, these procedure perform the frequency counts and generate the file of feedback data. The flag "-linstr" in the second example tells the linker to include the libinstr.so library, but the linker is unable to find it. I suggest to first make sure that you have build the libinstr.so library. Second, compile using the flags "-linstr -L", where is the location of the libinstr.so library. - David -- David Stephenson http://reality.sgi.com/dlstephe_engr/ From owner-pro64-support@oss.sgi.com Sun May 6 13:34:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f46KYuf12577 for pro64-support-outgoing; Sun, 6 May 2001 13:34:56 -0700 Received: from scapa.cs.ualberta.ca (root@scapa.cs.ualberta.ca [129.128.4.44]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f46KYtF12574 for ; Sun, 6 May 2001 13:34:55 -0700 Received: (from localhost user: 'pengzhao' uid#483 fake: STDIN (pengzhao@peers)) by scapa.cs.ualberta.ca id ; Sun, 6 May 2001 14:34:48 -0600 Date: Sun, 6 May 2001 14:34:47 -0600 (MDT) From: Peng Zhao To: David Stephenson cc: sgi Subject: Re: "paths" problem in pro64 In-Reply-To: <3AF5B363.65EE8D75@sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pro64-support@oss.sgi.com Precedence: bulk On Sun, 6 May 2001, David Stephenson wrote: Thanks. There is only libinstr.a instead of libinstr.so (even in the INSTALL script). A little confusing. I tried both -l and -L, both fails: ls ~/lib/gcc-lib/ia64-sgi-linux/sgicc-1.0/libinstr* /usr/brule12/grad/pengzhao/lib/gcc-lib/ia64-sgi-linux/sgicc-1.0/libinstr.a ls ~/lib gcc-lib/ libffio.a libfortran.a libmsgi.a libmv.a sgicc -fb_create ./test test.c -o test -linstr -L~/lib/gcc-lib/ia64-sgi-linux/sgicc-1.0 -L~/lib /usr/lib/gcc-lib/ia64-hp-linux/2.9-ia64-000216/../../../../ia64-hp-linux/bin/ld: cannot find -linstr collect2: ld returned 1 exit status sgicc -fb_create ./test test.c -o test -linstr /usr/lib/gcc-lib/ia64-hp-linux/2.9-ia64-000216/../../../../ia64-hp-linux/bin/ld: cannot find -linstr collect2: ld returned 1 exit status > Peng Zhao wrote: > > > And is there any neat solution to avoid > > "undefined reference to `__profile_pu_init'" error when using > > special libraries? Following are the tries I made: Can somebody explain > > me the related environment varialbes? > > > > ------------------- > > > > NUE>sgicc -fb_create ./test test.c -o test > > test.o:/usr/sakwatamau/brule12/grad/pengzhao/test/test.c:4: undefined > > reference to `__profile_init' test.o: In function `main': > > test.o(.text+0x72): undefined reference to `__profile_pu_init' > > test.o(.text+0x92): undefined reference to `__profile_invoke_init' > > test.o(.text+0xb2): undefined reference to `__profile_branch_init' > > test.o(.text+0xd2): undefined reference to `__profile_call_init' > > test.o(.text+0xf2): undefined reference to `__profile_invoke' > > test.o(.text+0x162): undefined reference to `__profile_branch' > > test.o(.text+0x1b2): undefined reference to `__profile_call_entry' > > test.o(.text+0x212): undefined reference to `__profile_call_exit' > > test.o(.text+0x252): undefined reference to `__profile_call_entry' > > test.o(.text+0x2b2): undefined reference to `__profile_call_exit' > > collect2: ld returned 1 exit status NUE:/usr/brule12/grad/pengzhao/test> > > ----------------------- > > NUE>sgicc -fb_create ./test test.c -o test -linstr > > /usr/lib/gcc-lib/ia64-hp-linux/2.9-ia64-000216/../../../../ia64-hp-linux/bin/ld: > > cannot find -linstr collect2: ld returned 1 exit status > > ------------------------ > > > __profile_init and the other undefined names are the names of procedures > in the libiinstr.so library used during instrumentation. During > compilation with instrumentation, calls to these procedures are inserted > into the WHIRL code of the program being compiled. When the instrumented > binary is run, these procedure perform the frequency counts and generate > the file of feedback data. > > The flag "-linstr" in the second example tells the linker to include the > libinstr.so library, but the linker is unable to find it. I suggest to > first make sure that you have build the libinstr.so library. Second, > compile using the flags "-linstr -L", where is the location > of the libinstr.so library. > > - David > > -- Regards Peng Peng Zhao pengzhao@cs.ualberta.ca http://www.cs.ualberta.ca/~pengzhao TEL (Lab): (780)492-3725 Lab: CSC251 From owner-pro64-support@oss.sgi.com Sun May 6 16:18:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f46NIHw15817 for pro64-support-outgoing; Sun, 6 May 2001 16:18:17 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f46NIGF15814 for ; Sun, 6 May 2001 16:18:16 -0700 Received: from gaea.engr.sgi.com (gaea.engr.sgi.com [130.62.180.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id QAA00445 for ; Sun, 6 May 2001 16:16:55 -0700 (PDT) mail_from (murthy@gaea.engr.sgi.com) Received: (from murthy@localhost) by gaea.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id QAA07712; Sun, 6 May 2001 16:14:05 -0700 (PDT) Date: Sun, 6 May 2001 16:14:05 -0700 (PDT) From: murthy@gaea.engr.sgi.com (Chandrasekhar Murthy) Message-Id: <200105062314.QAA07712@gaea.engr.sgi.com> To: sgi , Peng Zhao Subject: Re: "paths" problem in pro64 Sender: owner-pro64-support@oss.sgi.com Precedence: bulk For ipa_link, you need to specify -Yj, where dirname is the directory containing ipa_link. What is built in the ld directory is ld-new which is what ipa_link is a link to. Murthy From owner-pro64-support@oss.sgi.com Mon May 7 04:08:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f47B8UG29874 for pro64-support-outgoing; Mon, 7 May 2001 04:08:30 -0700 Received: from sunshine.math.utah.edu (IDENT:Ce1e/m5ADRitleUhmqkF+BgAhf4SLBC+@sunshine.math.utah.edu [128.110.198.2]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f47B8PF29870 for ; Mon, 7 May 2001 04:08:26 -0700 Received: from suncore.math.utah.edu (IDENT:oF37icfE7ZtAbp+bROWP2uYP8AfpTQhK@suncore0.math.utah.edu [128.110.198.5]) by sunshine.math.utah.edu (8.9.3/8.9.3) with ESMTP id FAA16207; Mon, 7 May 2001 05:08:19 -0600 (MDT) Received: (from beebe@localhost) by suncore.math.utah.edu (8.9.3/8.9.3) id FAA16285; Mon, 7 May 2001 05:08:15 -0600 (MDT) Date: Mon, 7 May 2001 05:08:15 -0600 (MDT) From: "Nelson H. F. Beebe" To: Peng Zhao Cc: beebe@math.utah.edu, sgi X-US-Mail: "Center for Scientific Computing, Department of Mathematics, 322 INSCC, University of Utah, 155 S 1400 E RM 233, Salt Lake City, UT 84112-0090, USA" X-Telephone: +1 801 581 5254 X-FAX: +1 801 585 1640, +1 801 581 4148 X-URL: http://www.math.utah.edu/~beebe Subject: Re: "paths" problem in pro64 Message-ID: Sender: owner-pro64-support@oss.sgi.com Precedence: bulk >> sgicc -fb_create ./test test.c -o test -linstr -L~/lib/gcc-lib/ia64-sgi-linux/sgicc-1.0 -L~/lib This won't work, for two reasons: (1) ~ is not expanded by the shell when it is embedded in a string; you must use the full absolute path, or else $HOME (-L$HOME/lib); (2) the -L switches must come before mention is made of -lxxx switches that tell what library to load. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - Center for Scientific Computing FAX: +1 801 585 1640, +1 801 581 4148 - - University of Utah Internet e-mail: beebe@math.utah.edu - - Department of Mathematics, 322 INSCC beebe@acm.org beebe@computer.org - - 155 S 1400 E RM 233 beebe@ieee.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe - ------------------------------------------------------------------------------- From owner-pro64-support@oss.sgi.com Mon May 7 06:27:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f47DRCF03120 for pro64-support-outgoing; Mon, 7 May 2001 06:27:12 -0700 Received: from mail.eecis.udel.edu (louie.udel.edu [128.175.2.33]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f47DRBF03112 for ; Mon, 7 May 2001 06:27:11 -0700 Received: from louie.udel.edu by mail.eecis.udel.edu id aa07404; 7 May 2001 09:26 EDT Date: Mon, 7 May 2001 09:26:48 -0400 (EDT) From: Haiping Wu To: pro64-support@oss.sgi.com MMDF-Warning: Parse error in original version of preceding line at mail.eecis.udel.edu cc: hu@tarlescu.capsl.udel.edu, hyang@capsl.udel.edu MMDF-Warning: Parse error in original version of preceding line at mail.eecis.udel.edu Subject: turn off predication function? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pro64-support@oss.sgi.com Precedence: bulk IA64 removes branches through the use of predication. I wonder if Ia64 can turn off this function and generate the general branchs without predication. Thanks! From owner-pro64-support@oss.sgi.com Mon May 7 09:28:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f47GStP14004 for pro64-support-outgoing; Mon, 7 May 2001 09:28:55 -0700 Received: from therouter.routefree.com ([209.21.47.226]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f47GStF14001 for ; Mon, 7 May 2001 09:28:55 -0700 Received: from routefree.com (IDENT:lo@osprey.routefree.com [10.0.0.35]) by therouter.routefree.com (8.9.3/8.9.3) with ESMTP id JAA21464; Mon, 7 May 2001 09:28:52 -0700 Message-ID: <3AF6CD43.1F27C320@routefree.com> Date: Mon, 07 May 2001 09:28:51 -0700 From: Raymond Lo Organization: RouteFree Inc. X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Haiping Wu CC: pro64-support@oss.sgi.com, hu@tarlescu.capsl.udel.edu, hyang@capsl.udel.edu Subject: Re: turn off predication function? References: Content-Type: text/plain; charset=big5 Content-Transfer-Encoding: 7bit Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Haiping Wu wrote: > IA64 removes branches through the use of predication. I wonder if Ia64 can > turn off this function and generate the general branchs without > predication. > > Thanks! I would recommend reading be/cg/cgdriver.cxx if you're interested in finer control of code generations. Search for *ifc* for if-conversion related flags. -Raymond From owner-pro64-support@oss.sgi.com Mon May 7 09:28:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f47GSv914018 for pro64-support-outgoing; Mon, 7 May 2001 09:28:57 -0700 Received: from calliope1.fm.intel.com (fmfdns01.fm.intel.com [132.233.247.10]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f47GSsF13998 for ; Mon, 7 May 2001 09:28:54 -0700 Received: from fmsmsx18.intel.com (fmsmsx18.fm.intel.com [132.233.233.232]) by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.36 2001/04/18 16:16:02 root Exp $) with ESMTP id QAA22732; Mon, 7 May 2001 16:28:43 GMT Received: by fmsmsx18.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 7 May 2001 09:26:03 -0700 Message-ID: <9287DC1579B0D411AA2F009027F44C3F042DFA81@FMSMSX41> From: "Chan, Sun C" To: "'Peng Zhao'" Cc: sgi Subject: RE: "paths" problem in pro64 Date: Mon, 7 May 2001 09:26:01 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-pro64-support@oss.sgi.com Precedence: bulk I noticed that -L didn't quite work for me also. Perhaps someone can shed some light. In the meantime, PengZhao, just specify "yourpath/libinstr.a" will work for you. Sun > -----Original Message----- > From: Peng Zhao [mailto:pengzhao@cs.ualberta.ca] > Sent: Sunday, May 06, 2001 1:35 PM > To: David Stephenson > Cc: sgi > Subject: Re: "paths" problem in pro64 > > > On Sun, 6 May 2001, David Stephenson wrote: > > Thanks. There is only libinstr.a instead of libinstr.so (even in the > INSTALL script). A little confusing. > > I tried both -l and -L, both fails: > > > ls ~/lib/gcc-lib/ia64-sgi-linux/sgicc-1.0/libinstr* > /usr/brule12/grad/pengzhao/lib/gcc-lib/ia64-sgi-linux/sgicc-1. > 0/libinstr.a > > ls ~/lib > gcc-lib/ libffio.a libfortran.a libmsgi.a libmv.a > > > sgicc -fb_create ./test test.c -o test -linstr > -L~/lib/gcc-lib/ia64-sgi-linux/sgicc-1.0 > -L~/lib > > /usr/lib/gcc-lib/ia64-hp-linux/2.9-ia64-000216/../../../../ia6 > 4-hp-linux/bin/ld: > cannot find -linstr > collect2: ld returned 1 exit status > > sgicc -fb_create ./test test.c -o test -linstr > /usr/lib/gcc-lib/ia64-hp-linux/2.9-ia64-000216/../../../../ia6 > 4-hp-linux/bin/ld: > cannot find -linstr > collect2: ld returned 1 exit status > > > > Peng Zhao wrote: > > > > > And is there any neat solution to avoid > > > "undefined reference to `__profile_pu_init'" error when using > > > special libraries? Following are the tries I made: Can > somebody explain > > > me the related environment varialbes? > > > > > > ------------------- > > > > > > NUE>sgicc -fb_create ./test test.c -o test > > > > test.o:/usr/sakwatamau/brule12/grad/pengzhao/test/test.c:4: undefined > > > reference to `__profile_init' test.o: In function `main': > > > test.o(.text+0x72): undefined reference to `__profile_pu_init' > > > test.o(.text+0x92): undefined reference to `__profile_invoke_init' > > > test.o(.text+0xb2): undefined reference to `__profile_branch_init' > > > test.o(.text+0xd2): undefined reference to `__profile_call_init' > > > test.o(.text+0xf2): undefined reference to `__profile_invoke' > > > test.o(.text+0x162): undefined reference to `__profile_branch' > > > test.o(.text+0x1b2): undefined reference to `__profile_call_entry' > > > test.o(.text+0x212): undefined reference to `__profile_call_exit' > > > test.o(.text+0x252): undefined reference to `__profile_call_entry' > > > test.o(.text+0x2b2): undefined reference to `__profile_call_exit' > > > collect2: ld returned 1 exit status > NUE:/usr/brule12/grad/pengzhao/test> > > > ----------------------- > > > NUE>sgicc -fb_create ./test test.c -o test -linstr > > > > /usr/lib/gcc-lib/ia64-hp-linux/2.9-ia64-000216/../../../../ia6 > 4-hp-linux/bin/ld: > > > cannot find -linstr collect2: ld returned 1 exit status > > > ------------------------ > > > > > > __profile_init and the other undefined names are the names > of procedures > > in the libiinstr.so library used during instrumentation. During > > compilation with instrumentation, calls to these procedures > are inserted > > into the WHIRL code of the program being compiled. When > the instrumented > > binary is run, these procedure perform the frequency counts > and generate > > the file of feedback data. > > > > The flag "-linstr" in the second example tells the linker > to include the > > libinstr.so library, but the linker is unable to find it. > I suggest to > > first make sure that you have build the libinstr.so > library. Second, > > compile using the flags "-linstr -L", where is > the location > > of the libinstr.so library. > > > > - David > > > > > > -- > Regards > > Peng > Peng Zhao pengzhao@cs.ualberta.ca > http://www.cs.ualberta.ca/~pengzhao > TEL (Lab): (780)492-3725 Lab: CSC251 > > > From owner-pro64-support@oss.sgi.com Mon May 7 10:43:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f47HhTT15947 for pro64-support-outgoing; Mon, 7 May 2001 10:43:29 -0700 Received: from mail.eecis.udel.edu (louie.udel.edu [128.175.2.33]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f47HhSF15944 for ; Mon, 7 May 2001 10:43:28 -0700 Received: from louie.udel.edu by mail.eecis.udel.edu id aa06704; 7 May 2001 13:43 EDT Date: Mon, 7 May 2001 13:43:16 -0400 (EDT) From: Haiping Wu To: Raymond Lo cc: pro64-support@oss.sgi.com MMDF-Warning: Parse error in original version of preceding line at mail.eecis.udel.edu Subject: No predication control in cgdriver.cxx? In-Reply-To: <3AF6CD43.1F27C320@routefree.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pro64-support@oss.sgi.com Precedence: bulk I have checked cgdriver.cxx. It seems no predication control option. From owner-pro64-support@oss.sgi.com Mon May 7 10:46:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f47Hkuu16100 for pro64-support-outgoing; Mon, 7 May 2001 10:46:56 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f47HktF16097 for ; Mon, 7 May 2001 10:46:55 -0700 Received: from rohi.engr.sgi.com (rohi.engr.sgi.com [130.62.180.74]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id KAA01203 for ; Mon, 7 May 2001 10:57:35 -0700 (PDT) mail_from (mpm@rohi.engr.sgi.com) Received: (from mpm@localhost) by rohi.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id KAA49837; Mon, 7 May 2001 10:41:36 -0700 (PDT) Date: Mon, 7 May 2001 10:41:36 -0700 (PDT) From: mpm@rohi.engr.sgi.com (Michael Murphy) Message-Id: <200105071741.KAA49837@rohi.engr.sgi.com> To: pro64-support@oss.sgi.com, Haiping Wu Subject: Re: turn off predication function? Cc: hyang@capsl.udel.edu, hu@tarlescu.capsl.udel.edu Sender: owner-pro64-support@oss.sgi.com Precedence: bulk IA64 removes branches through the use of predication. I wonder if Ia64 can turn off this function and generate the general branchs without predication. -CG:hb_formation=off. Of course even regular branches use predication, but this turns off the if conversion. -- Mike Murphy -- mpm@sgi.com -- quote of the day: -- "It is not what a man does that determines whether his work is -- sacred or secular, it is why he does it. -- The motive is everything." (A.W. Tozer) From owner-pro64-support@oss.sgi.com Mon May 7 11:26:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f47IQ5B18448 for pro64-support-outgoing; Mon, 7 May 2001 11:26:05 -0700 Received: from olsen.capsl.udel.edu (olsen.capsl.udel.edu [128.4.10.3]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f47IQ4F18445 for ; Mon, 7 May 2001 11:26:04 -0700 Received: from kakulavarapu.capsl.udel.edu (kakulavarapu.capsl.udel.edu [128.4.10.48]) by olsen.capsl.udel.edu (8.9.1/8.9.1) with SMTP id OAA03555 for ; Mon, 7 May 2001 14:26:02 -0400 (EDT) Date: Mon, 7 May 2001 14:26:02 -0400 (EDT) From: Hongbo Yang To: pro64-support@oss.sgi.com Subject: IPA (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pro64-support@oss.sgi.com Precedence: bulk We are getting linker errors when we are using the -IPA flag sgicc -O3 -IPA:INLINE=OFF dfe=ON -o reed_enc reed_enc.o rs.o sgicc ERROR: cannot exec /usr/lib/gcc-lib/ia64-sgi-linux/sgicc-1.0/ipa_link Is there a problem with what we are trying to do? --Yang From owner-pro64-support@oss.sgi.com Mon May 7 12:01:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f47J19D19309 for pro64-support-outgoing; Mon, 7 May 2001 12:01:09 -0700 Received: from pilsener.srv.ualberta.ca (pilsener.srv.ualberta.ca [129.128.5.19]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f47J14F19306 for ; Mon, 7 May 2001 12:01:04 -0700 Received: from webmail.ualberta.ca (webmail.srv.ualberta.ca [129.128.5.67]) by pilsener.srv.ualberta.ca (8.11.1/8.11.1) with ESMTP id f47J0sO04815 for ; Mon, 7 May 2001 13:00:54 -0600 (MDT) X-WebMail-UserID: pzhao Date: Mon, 7 May 2001 12:59:29 -0600 From: pzhao To: pro64-support X-EXP32-SerialNo: 00003228 Subject: RE: FWD: IPA Message-ID: <3AF78244@webmail.ualberta.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: WebMail (Hydra) SMTP v3.61 Sender: owner-pro64-support@oss.sgi.com Precedence: bulk do you use pro64 0.13? if not, use 0.13 instead of 0.12 If yes, I think u should check the availability of /usr/lib/gcc-lib/ia64-sgi-linux/sgicc-1.0/ipa_link maybe it is at a different place. use -Y,j or -Y,l to specify the directory. Hongbo, if you succeed in running the executable you generated, give me a message. Thank you. Do you use nue or an itanium machine? >===== Original Message From Hongbo Yang ===== >We are getting linker errors when we are using the -IPA flag > >sgicc -O3 -IPA:INLINE=OFF dfe=ON -o reed_enc reed_enc.o rs.o >sgicc ERROR: cannot exec /usr/lib/gcc-lib/ia64-sgi-linux/sgicc-1.0/ipa_link > >Is there a problem with what we are trying to do? > >--Yang From owner-pro64-support@oss.sgi.com Mon May 7 15:12:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f47MCZ924177 for pro64-support-outgoing; Mon, 7 May 2001 15:12:35 -0700 Received: from scapa.cs.ualberta.ca (root@scapa.cs.ualberta.ca [129.128.4.44]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f47MCLF24155 for ; Mon, 7 May 2001 15:12:35 -0700 Received: (from localhost user: 'pengzhao' uid#483 fake: STDIN (pengzhao@peers)) by scapa.cs.ualberta.ca id ; Mon, 7 May 2001 16:12:03 -0600 Date: Mon, 7 May 2001 16:12:02 -0600 (MDT) From: Peng Zhao To: sgi Subject: what is /lib/ld-linux-ia64.so.2 for? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Hi, Is it the incompatible thing metioned by sgi (new NUE based on libc2.2) ? Thank you. -- Regards Peng Peng Zhao pengzhao@cs.ualberta.ca http://www.cs.ualberta.ca/~pengzhao TEL (Lab): (780)492-3725 Lab: CSC251 From owner-pro64-support@oss.sgi.com Mon May 7 17:50:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f480o0628627 for pro64-support-outgoing; Mon, 7 May 2001 17:50:00 -0700 Received: from yowie.cc.uq.edu.au (root@yowie.cc.uq.edu.au [130.102.2.2]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f480nvF28621 for ; Mon, 7 May 2001 17:49:58 -0700 Received: from shake5.quakes.uq.edu.au (shake5.quakes.uq.edu.au [130.102.54.26]) by yowie.cc.uq.edu.au (8.9.3/8.9.3) with ESMTP id KAA24291 for ; Tue, 8 May 2001 10:49:55 +1000 (GMT+1000) Received: from localhost (hofer@localhost) by shake5.quakes.uq.edu.au (8.10.2/8.10.2) with ESMTP id f480ns0247389 for ; Tue, 8 May 2001 10:49:54 +1000 (EST) Date: Tue, 8 May 2001 10:49:54 +1000 From: Gerald Hofer To: pro64-support@oss.sgi.com Subject: Bug in gfecc Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pro64-support@oss.sgi.com Precedence: bulk We are running pro64-0.01.0-12 on an dual processor Itanium Box (B3) from Intel: $ uname -a Linux shake32 2.4.1-010131-8smp #1 SMP Wed Mar 7 13:04:24 PST 2001 ia64 unknown While compiling a custom code they are getting internal compiler errors. sggiCC -show indicates that the error is in gfecc. Error message: sgiCC ERROR: /usr/lib/gcc-lib/ia64-sgi-linux/sgicc-1.0/gfecc returned non-zero status 33 The following command produced the input for gfecc: $ /usr/bin/g++ -D__INLINE_INTRINSICS -D_LANGUAGE_C_PLUS_PLUS=1 -D_SGI_COMPILER_VERSION=001 -D__host_ia64 -D_X11_RELEASE_ -D_LINUX -DAdd_ -DUSE_VENDOR_BLAS -D_ADD__ -D_FORTRANLC -I/home/steffen/src/shake -I/home/steffen/src/shake/Model -I/home/steffen/src/shake/Model/Heat -I/home/steffen/src/shake/Display -I/home/steffen/src/shake/Display/X11-Windows -I/home/steffen/src/shake/Foundation -I/home/steffen/src/shake/Parser -I/home/steffen/src/shake/Main -I/home/steffen/src/shake/FileIO -I/home/steffen/src/shake/Display/Console -I/home/steffen/src/shake/MultiThread -I/home/steffen/src/shake/Foundation/SuperLU -I/home/steffen/src/shake/DmCoupler -I/usr/X11R6/include -D_LP64 -D__ia64=1 test.cpp -E > /tmp/out.i The following command produces the error: $ /usr/lib/gcc-lib/ia64-sgi-linux/sgicc-1.0/gfecc -O0 -dx -quiet -dumpbase functions.cpp /tmp/out.i -o /tmp/out2.i In file included from /home/steffen/src/shake/Foundation/console.h:10, from /home/steffen/src/shake/Model/particles.hpp:2, from /home/steffen/src/shake/Model/particles.h:264, from test.cpp:10: /usr/include/g++-3/strstream.h:85: Internal compiler error. /usr/include/g++-3/strstream.h:85: Please submit a full bug report. /usr/include/g++-3/strstream.h:85: See for instructions. The file out.i is the shortest version of the file where we could reproduce this bug. It is 204386 bytes long and can be downloaded from The code compiles without errors with g++. Regards, Gerald Hofer Q Queensland Q Gerald Hofer hofer@quakes.uq.edu.au Q U University U Supercomputer Manager U A Advanced A Department of Earth Sciences A K Centre for K The University of Queensland K E Earthquake E St Lucia QLD 4072 AUSTRALIA E S Studies S Ph: +61 7 3365 9774 Fax: +61 7 3365 7347 S From owner-pro64-support@oss.sgi.com Mon May 7 18:00:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4810nM29348 for pro64-support-outgoing; Mon, 7 May 2001 18:00:49 -0700 Received: from yowie.cc.uq.edu.au (root@yowie.cc.uq.edu.au [130.102.2.2]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4810kF29343 for ; Mon, 7 May 2001 18:00:47 -0700 Received: from shake5.quakes.uq.edu.au (shake5.quakes.uq.edu.au [130.102.54.26]) by yowie.cc.uq.edu.au (8.9.3/8.9.3) with ESMTP id LAA26013 for ; Tue, 8 May 2001 11:00:44 +1000 (GMT+1000) Received: from localhost (hofer@localhost) by shake5.quakes.uq.edu.au (8.10.2/8.10.2) with ESMTP id f4810ie247578 for ; Tue, 8 May 2001 11:00:44 +1000 (EST) Date: Tue, 8 May 2001 11:00:44 +1000 From: Gerald Hofer To: pro64-support@oss.sgi.com Subject: Re: Bug in gfecc In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pro64-support@oss.sgi.com Precedence: bulk On Tue, 8 May 2001, Gerald Hofer wrote: > We are running pro64-0.01.0-12 on an dual processor Itanium Box (B3) from Intel: Sorry - wrong version info: I have already upgraded to 0.01.0-13 - same bug. $ sgiCC -v SGIcc Compilers: Version 0.01.0-13 Regards, Gerald From owner-pro64-support@oss.sgi.com Tue May 8 09:30:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f48GUgY20573 for pro64-support-outgoing; Tue, 8 May 2001 09:30:42 -0700 Received: from artemis.rus.uni-stuttgart.de (artemis.rus.uni-stuttgart.de [129.69.1.28]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48GUbF20569 for ; Tue, 8 May 2001 09:30:41 -0700 Received: from baracke.rus.uni-stuttgart.de (baracke.rus.uni-stuttgart.de [129.69.58.100]) by artemis.rus.uni-stuttgart.de with ESMTP id SAA03385 for ; Tue, 8 May 2001 18:30:32 +0200 (MET DST) env-from (ruschelf@baracke.rus.uni-stuttgart.de) Received: (from ruschelf@localhost) by baracke.rus.uni-stuttgart.de (AIX4.3/UCB 8.8.8/8.8.8) id SAA79824 for pro64-support@oss.sgi.com; Tue, 8 May 2001 18:30:31 +0200 Date: Tue, 8 May 2001 18:30:31 +0200 From: Clemens Helf To: pro64-support@oss.sgi.com Subject: math library Message-ID: <20010508183031.G58836@baracke.rus.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Dear all, Is there a math library available, which is optimized for ia64 ? I could not find 'libm.a' or something like that in the compilers directories. Clemens Helf RUS/HLRS From owner-pro64-support@oss.sgi.com Tue May 8 10:37:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f48Hb6r22568 for pro64-support-outgoing; Tue, 8 May 2001 10:37:06 -0700 Received: from serenity.mcc.ac.uk (serenity.mcc.ac.uk [130.88.200.93]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48Hb4F22565 for ; Tue, 8 May 2001 10:37:04 -0700 Received: from nessie.mcc.ac.uk ([130.88.200.20] ident=root) by serenity.mcc.ac.uk with esmtp (Exim 2.05 #4) id 14xBPz-0003bZ-00 for pro64-support@oss.sgi.com; Tue, 8 May 2001 18:37:03 +0100 Received: from localhost (zzcgusp@localhost) by nessie.mcc.ac.uk (8.9.3/8.8.8) with ESMTP id SAA89555 for ; Tue, 8 May 2001 18:37:03 +0100 (BST) (envelope-from zzcgusp@nessie.mcc.ac.uk) Date: Tue, 8 May 2001 18:37:02 +0100 (BST) From: Stephen Pickles Reply-To: Stephen Pickles To: Pro64 Support Subject: fortran performance and array indexing Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-20758577-989343422=:89520" Sender: owner-pro64-support@oss.sgi.com Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-20758577-989343422=:89520 Content-Type: TEXT/PLAIN; charset=US-ASCII I hope this is the right place to report this kind of problem. If not, please set me straight. Fortran performance seems to depend sensitively on how arrays are indexed at the moment. Thus real x(n) do i=1,n ... enddo generates code that significantly outperforms real x(0:n-1) do i=0,n-1 ... enddo A test code is attached to this email, which shows a factor of nearly 5 in performance -- big enough to worry about as one doesn't always have the luxury of being able to choose how to index fortran arrays. I'm using sgif90 version 0.01.0-13 on a dual processor Troon, B1 stepping, and compiling like this: sgif90 -O3 -LNO:blocking=off matmul_test.f Is this a known problem? Should I wait for it to be fixed or should I work around it? Best regards, Stephen ==================== Stephen M. Pickles ==================== CSAR Technology Refresh Team Leader s.pickles@man.ac.uk Manchester Computing Room G49-B, Kilburn Building tel: +44 161 275 5974 The University of Manchester fax: +44 161 275 6800 Oxford Road Manchester M13 9PL http://www.csar.cfs.ac.uk/ ===========================(*,*)============================ --0-20758577-989343422=:89520 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="matmul_test.f" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="matmul_test.f" ICAgICAgcHJvZ3JhbSBtYXRtdWxfdGVzdA0KICAgICAgaW1wbGljaXQgbm9u ZQ0KICAgICAgaW50ZWdlciB2ZWNsZW4sbnJ1bnMsaWNvdW50LGkNCiAgICAg IGludGVnZXIgbmRpbTEsbmRpbTIsbmRpbTMNCiAgICAgIHBhcmFtZXRlciAo dmVjbGVuPTgwLG5ydW5zPTEwMDAwMCkNCiAgICAgIHBhcmFtZXRlciAobmRp bTE9NCxuZGltMj00LG5kaW0zPTQpDQogICAgICByZWFsIHQsIHQwLCB0MQ0K ICAgICAgcmVhbCo4IGEobmRpbTEsbmRpbTMpDQogICAgICByZWFsKjggYihu ZGltMixuZGltMyx2ZWNsZW4pDQogICAgICByZWFsKjggYyhuZGltMixuZGlt MSx2ZWNsZW4pDQogICAgICByZWFsKjggZChuZGltMixuZGltMSx2ZWNsZW4p DQogICAgICByZWFsKjggZGlmZg0KDQogICAgICBpY291bnQ9MipuZGltMSpu ZGltMipuZGltMyp2ZWNsZW4qbnJ1bnMNCiAgICAgIGNhbGwgbWFrZW1hdHMo bmRpbTEsbmRpbTIsbmRpbTMsdmVjbGVuLGEsYikNCg0KICAgICAgYz0wLjAJ DQogICAgICBjYWxsIGNwdV90aW1lKHQwKQ0KICAgICAgZG8gaT0xLG5ydW5z DQogICAgICAgIGNhbGwgbWV0aG9kMShuZGltMSxuZGltMixuZGltMyx2ZWNs ZW4sYSxiLGMpDQogICAgICBlbmRkbw0KICAgICAgY2FsbCBjcHVfdGltZSh0 MSkNCiAgICAgIHQgPSB0MS10MA0KICAgICAgd3JpdGUoNiwqKSdzcGVlZCgx KSA9JyxyZWFsKGljb3VudCkvKDEwMDAwMDAuKnQpDQoNCiAgICAgIGQ9MC4w DQogICAgICBjYWxsIGNwdV90aW1lKHQwKQ0KICAgICAgZG8gaT0xLG5ydW5z DQogICAgICAgIGNhbGwgbWV0aG9kMihuZGltMSxuZGltMixuZGltMyx2ZWNs ZW4sYSxiLGQpDQogICAgICBlbmRkbw0KICAgICAgY2FsbCBjcHVfdGltZSh0 MSkNCiAgICAgIHQgPSB0MS10MA0KICAgICAgd3JpdGUoNiwqKSdzcGVlZCgy KSA9JyxyZWFsKGljb3VudCkvKDEwMDAwMDAuKnQpDQogICAgICBjYWxsIGRp ZmYyKG5kaW0yKm5kaW0zKnZlY2xlbixjLGQsZGlmZikNCiAgICAgIHdyaXRl KDYsKiknZGlzY3JlcGFuY3kgPScsZGlmZg0KDQogICAgICBzdG9wIA0KICAg ICAgZW5kIHByb2dyYW0gbWF0bXVsX3Rlc3QNCg0KICAgICAgc3Vicm91dGlu ZSBtYWtlbWF0cyhuZGltMSxuZGltMixuZGltMyx2ZWNsZW4sYSxiKQ0KICAg ICAgaW1wbGljaXQgbm9uZQ0KICAgICAgaW50ZWdlciBuZGltMSxuZGltMixu ZGltMyx2ZWNsZW4saSxqLGsNCiAgICAgIHJlYWwqOCBhKG5kaW0xLG5kaW0z KQ0KICAgICAgcmVhbCo4IGIobmRpbTIsbmRpbTMsdmVjbGVuKQ0KICAgICAg ZG8gaj0xLG5kaW0zDQogICAgICAgIGRvIGk9MSxuZGltMQ0KICAgICAgICAg IGEoaSxqKT1rK2krag0KICAgICAgICBlbmRkbw0KICAgICAgZW5kZG8NCiAg ICAgIGRvIGs9MSx2ZWNsZW4NCiAgICAgICAgZG8gaj0xLG5kaW0zDQogICAg ICAgICAgZG8gaT0xLG5kaW0yDQogICAgICAgICAgICBiKGksaixrKT1rLWkt ag0KICAgICAgICAgIGVuZGRvDQogICAgICAgIGVuZGRvDQogICAgICBlbmRk bw0KICAgICAgcmV0dXJuIA0KICAgICAgZW5kIHN1YnJvdXRpbmUgbWFrZW1h dHMNCg0KICAgICAgc3Vicm91dGluZSBkaWZmMihuLGMsZCxkaWZmKQ0KICAg ICAgaW1wbGljaXQgbm9uZQ0KICAgICAgaW50ZWdlciBuLGkNCiAgICAgIHJl YWwqOCBjKG4pLCBkKG4pDQogICAgICByZWFsKjggZGlmZg0KICAgICAgZGlm ZiA9IDAuMA0KICAgICAgZG8gaT0xLG4NCiAgICAgICAgZGlmZiA9IGRpZmYg KyAoYyhpKS1kKGkpKSoqMg0KICAgICAgZW5kZG8NCiAgICAgIHJldHVybiAN CiAgICAgIGVuZCBzdWJyb3V0aW5lIGRpZmYyDQoNCiAgICAgIHN1YnJvdXRp bmUgbWV0aG9kMShuZGltMSxuZGltMixuZGltMyx2ZWNsZW4sYSxiLGMpDQog ICAgICBpbXBsaWNpdCBub25lDQogICAgICBpbnRlZ2VyLCBpbnRlbnQoaW4p ICAgOjogbmRpbTEsbmRpbTIsbmRpbTMsdmVjbGVuDQogICAgICByZWFsKjgs IGludGVudChpbikgICAgOjogYSgwOm5kaW0xLTEsMDpuZGltMy0xKQ0KICAg ICAgcmVhbCo4LCBpbnRlbnQoaW4pICAgIDo6IGIoMDpuZGltMi0xLDA6bmRp bTMtMSwwOnZlY2xlbi0xKQ0KICAgICAgcmVhbCo4LCBpbnRlbnQoaW5vdXQp IDo6IGMoMDpuZGltMi0xLDA6bmRpbTEtMSwwOnZlY2xlbi0xKQ0KICAgICAg aW50ZWdlciA6OiBpLG4xLG4yLG4zDQogICAgICBkbyBpPTAsdmVjbGVuLTEN CiAgICAgICAgZG8gbjM9MCxuZGltMy0xDQogICAgICAgICAgZG8gbjE9MCxu ZGltMS0xDQogICAgICAgICAgICBkbyBuMj0wLG5kaW0yLTENCiAgICAgICAg ICAgICAgYyhuMixuMSxpKT1jKG4yLG4xLGkpK2EobjEsbjMpKmIobjIsbjMs aSkNCiAgICAgICAgICAgIGVuZGRvDQogICAgICAgICAgZW5kZG8NCiAgICAg ICAgZW5kZG8NCiAgICAgIGVuZGRvDQogICAgICByZXR1cm4NCiAgICAgIGVu ZCBzdWJyb3V0aW5lDQoNCiAgICAgIHN1YnJvdXRpbmUgbWV0aG9kMihuZGlt MSxuZGltMixuZGltMyx2ZWNsZW4sYSxiLGMpDQogICAgICBpbXBsaWNpdCBu b25lDQogICAgICBpbnRlZ2VyLCBpbnRlbnQoaW4pICAgOjogbmRpbTEsbmRp bTIsbmRpbTMsdmVjbGVuDQogICAgICByZWFsKjgsIGludGVudChpbikgICAg OjogYShuZGltMSxuZGltMykNCiAgICAgIHJlYWwqOCwgaW50ZW50KGluKSAg ICA6OiBiKG5kaW0yLG5kaW0zLHZlY2xlbikNCiAgICAgIHJlYWwqOCwgaW50 ZW50KGlub3V0KSA6OiBjKG5kaW0yLG5kaW0xLHZlY2xlbikNCiAgICAgIGlu dGVnZXIgOjogaSxuMSxuMixuMw0KICAgICAgZG8gaT0xLHZlY2xlbg0KICAg ICAgICBkbyBuMz0xLG5kaW0zDQogICAgICAgICAgZG8gbjE9MSxuZGltMQ0K ICAgICAgICAgICAgZG8gbjI9MSxuZGltMg0KICAgICAgICAgICAgICBjKG4y LG4xLGkpPWMobjIsbjEsaSkrYShuMSxuMykqYihuMixuMyxpKQ0KICAgICAg ICAgICAgZW5kZG8NCiAgICAgICAgICBlbmRkbw0KICAgICAgICBlbmRkbw0K ICAgICAgZW5kZG8NCiAgICAgIHJldHVybg0KICAgICAgZW5kIHN1YnJvdXRp bmUNCg0K --0-20758577-989343422=:89520-- From owner-pro64-support@oss.sgi.com Tue May 8 10:57:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f48HvPJ23347 for pro64-support-outgoing; Tue, 8 May 2001 10:57:25 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48HvOF23344 for ; Tue, 8 May 2001 10:57:24 -0700 Received: from rohi.engr.sgi.com (rohi.engr.sgi.com [130.62.180.74]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id KAA11652 for ; Tue, 8 May 2001 10:56:02 -0700 (PDT) mail_from (mpm@rohi.engr.sgi.com) Received: (from mpm@localhost) by rohi.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id KAA53166; Tue, 8 May 2001 10:53:22 -0700 (PDT) Date: Tue, 8 May 2001 10:53:22 -0700 (PDT) From: mpm@rohi.engr.sgi.com (Michael Murphy) Message-Id: <200105081753.KAA53166@rohi.engr.sgi.com> To: pro64-support@oss.sgi.com, Clemens Helf Subject: Re: math library Sender: owner-pro64-support@oss.sgi.com Precedence: bulk We use the standard libm.a that comes from gcc. But we also ship libmsgi.a and libmv.a, which have extra math utilities. If you specify -lm on the link line, it will automagically add -lmv -lmsgi after -lm. -- Mike Murphy -- mpm@sgi.com -- quote of the day: -- "How do you make God laugh? Tell him your plans." From owner-pro64-support@oss.sgi.com Tue May 8 11:16:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f48IGsw24282 for pro64-support-outgoing; Tue, 8 May 2001 11:16:54 -0700 Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48IGsF24279 for ; Tue, 8 May 2001 11:16:54 -0700 Received: from SMTP (fmsmsxvs02-1.fm.intel.com [132.233.42.202]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.36 2001/04/18 16:16:02 root Exp $) with SMTP id SAA09644; Tue, 8 May 2001 18:16:24 GMT Received: from fmsmsx18.intel.com ([132.233.48.18]) by 132.233.48.202 (Norton AntiVirus for Internet Email Gateways 1.0) ; Tue, 08 May 2001 18:16:24 0000 (GMT) Received: by fmsmsx18.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 8 May 2001 11:16:22 -0700 Message-ID: <9287DC1579B0D411AA2F009027F44C3F042DFA8C@FMSMSX41> From: "Chan, Sun C" To: "'Clemens Helf'" , pro64-support@oss.sgi.com Subject: RE: math library Date: Tue, 8 May 2001 11:16:18 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-pro64-support@oss.sgi.com Precedence: bulk There is a libm.so and libm.a in /lib, under the nue environment. Intel also has an open sourced libm, I believe although I don't know where it is. In the osprey1.0 source tree, look at libm directory. I believe this library is optimized for ia64. Sun > -----Original Message----- > From: Clemens Helf [mailto:helf@RUS.Uni-Stuttgart.DE] > Sent: Tuesday, May 08, 2001 9:31 AM > To: pro64-support@oss.sgi.com > Subject: math library > > > Dear all, > > Is there a math library available, which is optimized for ia64 ? > I could not find 'libm.a' or something like that in the compilers > directories. > > Clemens Helf > RUS/HLRS > From owner-pro64-support@oss.sgi.com Tue May 8 11:20:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f48IK5624502 for pro64-support-outgoing; Tue, 8 May 2001 11:20:05 -0700 Received: from sunshine.math.utah.edu (IDENT:xUoyRm2eO0st+jLKmLv0MvFVFhVNFUsi@sunshine.math.utah.edu [128.110.198.2]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48IK4F24498 for ; Tue, 8 May 2001 11:20:04 -0700 Received: from suncore.math.utah.edu (IDENT:YqvFJBN7ofRmQLoY+c/zvPQDrhKbsC/9@suncore0.math.utah.edu [128.110.198.5]) by sunshine.math.utah.edu (8.9.3/8.9.3) with ESMTP id MAA06133; Tue, 8 May 2001 12:20:02 -0600 (MDT) Received: (from beebe@localhost) by suncore.math.utah.edu (8.9.3/8.9.3) id MAA08218; Tue, 8 May 2001 12:20:01 -0600 (MDT) Date: Tue, 8 May 2001 12:20:01 -0600 (MDT) From: "Nelson H. F. Beebe" To: Stephen Pickles Cc: beebe@math.utah.edu, Pro64 Support X-US-Mail: "Center for Scientific Computing, Department of Mathematics, 322 INSCC, University of Utah, 155 S 1400 E RM 233, Salt Lake City, UT 84112-0090, USA" X-Telephone: +1 801 581 5254 X-FAX: +1 801 585 1640, +1 801 581 4148 X-URL: http://www.math.utah.edu/~beebe Subject: Re: fortran performance and array indexing Message-ID: Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Stephen Pickles writes on Tue, 8 May 2001 18:37:02 +0100 (BST) about a performance difference in Fortran 90 matrix multiplication seen with the SGI Pro64 compilers on IA-64. I took the sample code and ran it on a number of other architectures, with the results shown below. Notice that method 2 (0-based indexing) is notably slower on the Intel Pentium III system, but slightly faster on six other systems. I repeated several of these runs, without seeing any significant difference in the reported timings. Stephen's message did not make clear whether his results were for native IA-64 hardware, or for the NUE IA-64 emulator environment. Mine are for the latter, and they demonstrate a 2.7x slowdown for 0-based indexing. Given that the same number of loads and stores, and the same number of floating-point operations, is required in each case, these differences are puzzling, and further examination of the generated assembly code will likely be necessary to resolve the question. The .s file is over 10K lines long, and I wasn't able to quickly isolate in a text editor the relevant code bodies for comparison. Compaq/DEC Alpha 4100-5/466 OSF/1 4.0F f95 -O3 matmul_test.f && ./a.out speed(1) = 128.8102 speed(2) = 126.6855 discrepancy = 0.000000000000000E+000 Compaq AlphaServer ES40 Sierra/667 (32 EV6.7 21264A CPUs, 667 MHz, 8GB RAM); OSF/1 5.0 f95 -O5 matmul_test.f && ./a.out speed(1) = 84.92637 speed(2) = 86.62321 discrepancy = 0.000000000000000E+000 Compaq AlphaServer ES40 DEC6600/500 (8 EV6 21264 CPUs, 500 MHz, 8GB RAM); OSF/1 4.0F f95 -O5 matmul_test.f && ./a.out speed(1) = 155.6647 speed(2) = 150.3770 discrepancy = 0.000000000000000E+000 IBM SP/2 AIX 4.3 xlf95 -O1 matmul_test.f && ./a.out speed(1) = 7.607727051 speed(2) = 7.227553844 discrepancy = 0.000000000000000000E+00 Intel Pentium III GNU/Linux 2.2.17-14smp (Red Hat 6.2) lf95 -O3 matmul_test.f -o foo.exe && ./foo.exe speed(1) = 87.0748291 speed(2) = 97.8032532 discrepancy = 0.000000000000000E+00 Intel Pentium III GNU/Linux 2.2.17-14smp (Red Hat 6.2) HP NUE IA-64 emulator (reduced nruns from 100000 to 1000) sgif90 -O3 matmul_test.f && ./a.out speed(1) = 0.207665801 speed(2) = 0.565433443 discrepancy = 0.E+0 SGI R5000-PC IRIX 6.5 f90 -O3 matmul_test.f && ./a.out speed(1) = 36.2537994 speed(2) = 34.8822517 discrepancy = 0.E+0 SGI Origin 200 IRIX 6.5 f90 -O3 matmul_test.f && ./a.out speed(1) = 75.4860535 speed(2) = 68.8059082 discrepancy = 0.E+0 Sun SPARC Solaris 2.7 f95 -O3 matmul_test.f && ./a.out speed(1) = 53.20448 speed(2) = 51.201023 discrepancy = 0.0E+0 As an aside, see http://www.math.utah.edu/pub/benchmarks/usirep.pdf http://www.math.utah.edu/pub/benchmarks/usirep.ps for ways to sometimes dramatically speed-up matrix multiplication on modern RISC systems. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - Center for Scientific Computing FAX: +1 801 585 1640, +1 801 581 4148 - - University of Utah Internet e-mail: beebe@math.utah.edu - - Department of Mathematics, 322 INSCC beebe@acm.org beebe@computer.org - - 155 S 1400 E RM 233 beebe@ieee.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe - ------------------------------------------------------------------------------- From owner-pro64-support@oss.sgi.com Tue May 8 15:24:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f48MOvT02042 for pro64-support-outgoing; Tue, 8 May 2001 15:24:57 -0700 Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48MOvF02039 for ; Tue, 8 May 2001 15:24:57 -0700 Received: from SMTP (fmsmsxvs02-1.fm.intel.com [132.233.42.202]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.36 2001/04/18 16:16:02 root Exp $) with SMTP id WAA19390 for ; Tue, 8 May 2001 22:24:52 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.48.29]) by 132.233.48.202 (Norton AntiVirus for Internet Email Gateways 1.0) ; Tue, 08 May 2001 22:24:51 0000 (GMT) Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 8 May 2001 15:24:50 -0700 Message-ID: <7B3D67AA81EBD111AC4000A0C96B23F70A7A791E@orsmsx32.jf.intel.com> From: "Kubaska, Theodore E" To: "'pro64-support@oss.sgi.com'" Subject: I'm getting a virus from Date: Tue, 8 May 2001 15:24:40 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-pro64-support@oss.sgi.com Precedence: bulk pro64-0.01.0-13-sources.tar.gz >From McAffee but not specific about the name of virus. Do you know about this? -Ted Kubaska Intel 505 696 3241 From owner-pro64-support@oss.sgi.com Tue May 8 15:35:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f48MZrb02317 for pro64-support-outgoing; Tue, 8 May 2001 15:35:53 -0700 Received: from mail.us.tlan (munch-it.turbolinux.com [38.170.88.129]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48MZqF02314 for ; Tue, 8 May 2001 15:35:52 -0700 Received: (from nobody@localhost) by mail.us.tlan (8.9.3/8.9.3) id PAA05132; Tue, 8 May 2001 15:35:51 -0700 Received: from UNKNOWN(172.16.14.242), claiming to be "drevil.dev.us.tlan" via SMTP by mail.us.tlan, id smtpdnsz33o; Tue May 8 15:35:46 2001 Received: (from mmadore@localhost) by drevil.dev.us.tlan (8.9.3/8.9.3) id PAA24694; Tue, 8 May 2001 15:35:53 -0700 Date: Tue, 8 May 2001 15:35:53 -0700 From: Michael Madore To: "Kubaska, Theodore E" Cc: "'pro64-support@oss.sgi.com'" Subject: Re: I'm getting a virus from Message-ID: <20010508153552.A24429@drevil.no> References: <7B3D67AA81EBD111AC4000A0C96B23F70A7A791E@orsmsx32.jf.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <7B3D67AA81EBD111AC4000A0C96B23F70A7A791E@orsmsx32.jf.intel.com>; from theodore.e.kubaska@intel.com on Tue, May 08, 2001 at 03:24:40PM -0700 Sender: owner-pro64-support@oss.sgi.com Precedence: bulk I think the virus checker is probably getting confused. Where did you get the source file from? On Tue, May 08, 2001 at 03:24:40PM -0700, Kubaska, Theodore E wrote: > pro64-0.01.0-13-sources.tar.gz > > >From McAffee but not specific about the name of virus. Do you know about > this? > -Ted Kubaska > Intel > 505 696 3241 -- Mike Madore Senior Software Engineer TurboLinux, Inc. (650)228-5203 From owner-pro64-support@oss.sgi.com Tue May 8 16:00:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f48N0fC02876 for pro64-support-outgoing; Tue, 8 May 2001 16:00:41 -0700 Received: from sunshine.math.utah.edu (IDENT:u4KWOgMIt1fO7DICWOPisuypGGTgTgxd@sunshine.math.utah.edu [128.110.198.2]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48N0eF02873 for ; Tue, 8 May 2001 16:00:40 -0700 Received: from suncore.math.utah.edu (IDENT:zMFm8FIMXLGoIg6p3QQ8WzRZFkFHdjpw@suncore0.math.utah.edu [128.110.198.5]) by sunshine.math.utah.edu (8.9.3/8.9.3) with ESMTP id RAA10189; Tue, 8 May 2001 17:00:38 -0600 (MDT) Received: (from beebe@localhost) by suncore.math.utah.edu (8.9.3/8.9.3) id RAA02806; Tue, 8 May 2001 17:00:32 -0600 (MDT) Date: Tue, 8 May 2001 17:00:32 -0600 (MDT) From: "Nelson H. F. Beebe" To: "Kubaska, Theodore E" , Michael Madore Cc: beebe@math.utah.edu, pro64-support@oss.sgi.com X-US-Mail: "Center for Scientific Computing, Department of Mathematics, 322 INSCC, University of Utah, 155 S 1400 E RM 233, Salt Lake City, UT 84112-0090, USA" X-Telephone: +1 801 581 5254 X-FAX: +1 801 585 1640, +1 801 581 4148 X-URL: http://www.math.utah.edu/~beebe Subject: Re: I'm getting a virus from pro64-0.01.0-13-sources.tar.gz Message-ID: Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Here are checksums at my site for the file for which your virus checker is complaining; I downloaded this file from the SGI site on 2001.04.25 15:21:14. % md5 pro64-0.01.0-13-sources.tar.gz MD5 (pro64-0.01.0-13-sources.tar.gz) = 2301e2c0d2b0a3fd3c2ccf844dd8a976 % sha pro64-0.01.0-13-sources.tar.gz B9440600 E7C2F18F 1550C2D6 2FD405F0 C31953FC % sha1sum pro64-0.01.0-13-sources.tar.gz b39dd009f4449502359d170ae5e6278851e0e35d pro64-0.01.0-13-sources.tar.gz % sha256 pro64-0.01.0-13-sources.tar.gz pro64-0.01.0-13-sources.tar.gz: c7d53694 802a3cea 6d692691 87b3c44d 7ae85a13 cc9b8989 89d2106c 3a93edeb % sha384 pro64-0.01.0-13-sources.tar.gz pro64-0.01.0-13-sources.tar.gz: b2c9ebe12958746d 3d6a715bfbb2563e c8a72febb2ccae6a cb1212e8846460ba 64a5039e196291ce b5c92739b70409c7 You should be able to verify one or more of these at your site. md5 and sha are available at ftp://ftp.math.utah.edu/pub/md5.tar.gz (and also in .jar, .zip, and .zoo forms there). sha1sum, sha256, and sha384 are part of recent GNU textutils releases, e.g., ftp://ftp.gnu.org/pub/gnu/textutils/textutils-2.0.14.tar.gz It would be helpful if the SGI Web site posted checksums for such files, preferably stored in a read-only file system. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - Center for Scientific Computing FAX: +1 801 585 1640, +1 801 581 4148 - - University of Utah Internet e-mail: beebe@math.utah.edu - - Department of Mathematics, 322 INSCC beebe@acm.org beebe@computer.org - - 155 S 1400 E RM 233 beebe@ieee.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe - ------------------------------------------------------------------------------- From owner-pro64-support@oss.sgi.com Tue May 8 16:02:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f48N2KV03167 for pro64-support-outgoing; Tue, 8 May 2001 16:02:20 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48N2GF03161 for ; Tue, 8 May 2001 16:02:16 -0700 Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id BAA1016612 for ; Wed, 9 May 2001 01:02:14 +0200 (CEST) mail_from (jbaron@sgi.com) Received: from coolguy.engr.sgi.com (coolguy.engr.sgi.com [130.62.176.135]) by cthulhu.engr.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id QAA49504; Tue, 8 May 2001 16:00:56 -0700 (PDT) Received: from sgi.com (coolguy.engr.sgi.com [130.62.176.135]) by coolguy.engr.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id QAA06455; Tue, 8 May 2001 16:00:06 -0700 (PDT) Message-ID: <3AF87A76.989A3B76@sgi.com> Date: Tue, 08 May 2001 16:00:06 -0700 From: John Baron Reply-To: jbaron@sgi.com Organization: SGI Compute Intensive Applications X-Mailer: Mozilla 4.75C-SGI [en] (X11; I; IRIX64 6.5-ALPHA-1277214920 IP30) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Pickles CC: Pro64 Support Subject: Re: fortran performance and array indexing References: Content-Type: multipart/mixed; boundary="------------BD45B233F9A79E5864027759" Sender: owner-pro64-support@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------BD45B233F9A79E5864027759 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Stephen Pickles wrote: > Is this a known problem? Should I wait for it to be fixed or should > I work around it? Hi Stephen, This sure seems like a bug to me -- I'm attaching the WHIRL-to-Fortran output, where it's clear that in method1() no extra computations are being exposed, while in method2() the compiler is unrolling the outer loops 4x4. I will file a bug in our internal tracking system on this. I have no idea when it might be addressed, however. Thanks for pointing this out, John -- John Baron jbaron@sgi.com SGI Performance Engineering and Math Libraries --------------BD45B233F9A79E5864027759 Content-Type: text/plain; charset=us-ascii; name="matmul.w2f.f" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="matmul.w2f.f" C *********************************************************** C Fortran file translated from WHIRL Tue May 8 13:42:54 2001 C *********************************************************** PROGRAM MAIN IMPLICIT NONE C C **** Variables and functions **** C REAL(8) A(4_8, 4_8) REAL(8) B(4_8, 4_8, 80_8) REAL(8) C(4_8, 4_8, 80_8) REAL(8) D(4_8, 4_8, 80_8) REAL(8) DIFF INTEGER(4) I INTEGER(4) ICOUNT REAL(4) T REAL(4) T0 REAL(4) T1 EXTERNAL _CPU_TIME_4 C C **** Temporary variables **** C INTEGER(8) f90li_1_1 INTEGER(8) f90li_2_1 INTEGER(8) f90li_0_1 INTEGER(8) f90li_1_2 INTEGER(8) f90li_2_2 INTEGER(8) f90li_0_2 INTEGER(4) I0 C C **** statements **** C ICOUNT = 1024000000 CALL makemats(4, 4, 4, 80, A, B) DO f90li_1_1 = 0, 3, 1 DO f90li_2_1 = 0, 3, 2 DO f90li_0_1 = 0, 79, 1 C(f90li_2_1 + 1, f90li_1_1 + 1, f90li_0_1 + 1) = 0.0D00 C(f90li_2_1 + 2_8, f90li_1_1 + 1, f90li_0_1 + 1) = 0.0D00 END DO END DO END DO CALL _CPU_TIME_4(T0) DO I = 1, 100000, 1 CALL method1(4, 4, 4, 80, A, B, C) END DO CALL _CPU_TIME_4(T1) T = (T1 - T0) WRITE(6, *) 'speed(1) =', (REAL(ICOUNT) /((T * 1.0E+06))) DO f90li_1_2 = 0, 3, 1 DO f90li_2_2 = 0, 3, 2 DO f90li_0_2 = 0, 79, 1 D(f90li_2_2 + 1, f90li_1_2 + 1, f90li_0_2 + 1) = 0.0D00 D(f90li_2_2 + 2_8, f90li_1_2 + 1, f90li_0_2 + 1) = 0.0D00 END DO END DO END DO CALL _CPU_TIME_4(T0) DO I0 = 1, 100000, 1 CALL method2(4, 4, 4, 80, A, B, D) END DO CALL _CPU_TIME_4(T1) T = (T1 - T0) WRITE(6, *) 'speed(2) =', (REAL(ICOUNT) /((T * 1.0E+06))) CALL diff2(1280, C, D, DIFF) WRITE(6, *) 'discrepancy =', DIFF STOP END SUBROUTINE makemats(NDIM1, NDIM2, NDIM3, VECLEN, A, B) IMPLICIT NONE INTEGER(4) NDIM1 INTEGER(4) NDIM2 INTEGER(4) NDIM3 INTEGER(4) VECLEN REAL(8) A(t$5, t$6) REAL(8) B(t$7, t$6, t$8) C C **** Variables and functions **** C INTEGER(8) t$5 INTEGER(8) t$9 INTEGER(8) t$6 INTEGER(8) t$11 INTEGER(8) t$7 INTEGER(8) t$13 INTEGER(8) t$8 INTEGER(8) t$16 INTEGER(4) I INTEGER(4) J INTEGER(4) K INTEGER(8) t$10 INTEGER(8) t$12 INTEGER(8) t$14 INTEGER(8) t$15 INTEGER(8) t$17 C C **** Temporary variables **** C INTEGER(4) tmp0_I_0 INTEGER(4) wd_J INTEGER(4) I1 INTEGER(4) wd_$wd_J INTEGER(4) I2 INTEGER(4) J0 INTEGER(4) I0 INTEGER(4) wd_J1 INTEGER(4) I3 INTEGER(4) wd_$wd_J1 INTEGER(4) I4 INTEGER(4) wd_K INTEGER(4) J1 INTEGER(4) I5 INTEGER(4) wd_J0 INTEGER(4) I6 INTEGER(4) wd_$wd_J0 INTEGER(4) I7 C C **** statements **** C t$5 = NDIM1 t$6 = NDIM3 t$9 = MAX(NDIM1, 0) t$10 = (MAX(NDIM1, 0) * 2) t$11 = MAX(NDIM3, 0) t$12 = (MAX(NDIM1, 0) * MAX(NDIM3, 0)) t$7 = NDIM2 t$8 = VECLEN t$13 = MAX(NDIM2, 0) t$14 = (MAX(NDIM2, 0) * 2) t$15 = ((MAX(NDIM2, 0) * MAX(NDIM3, 0)) * 2) t$16 = MAX(VECLEN, 0) t$17 = (MAX(NDIM2, 0) *(MAX(NDIM3, 0) * MAX(VECLEN, 0))) DO J = 1, (NDIM3 + -7_8), 8 IF(NDIM1 .GE. 1) THEN tmp0_I_0 = (J + K) DO I = 1, NDIM1, 1 A(I, J) = DBLE((J +(I + K))) A(I, J + 1) = DBLE(((I + tmp0_I_0) + 1)) A(I, J + 2) = DBLE(((I + tmp0_I_0) + 2)) A(I, J + 3) = DBLE(((I + tmp0_I_0) + 3)) A(I, J + 4) = DBLE(((I + tmp0_I_0) + 4)) A(I, J + 5) = DBLE(((I + tmp0_I_0) + 5)) A(I, J + 6) = DBLE(((I + tmp0_I_0) + 6)) A(I, J + 7) = DBLE(((I + tmp0_I_0) + 7)) END DO ENDIF END DO DO wd_J = J, NDIM3 + -1, 2 DO I1 = 1, NDIM1, 1 A(I1, wd_J) = DBLE((wd_J +(K + I1))) A(I1, wd_J + 1) = DBLE(((wd_J +(K + I1)) + 1)) END DO END DO DO wd_$wd_J = wd_J, NDIM3, 1 DO I2 = 1, NDIM1, 1 A(I2, wd_$wd_J) = DBLE((wd_$wd_J +(K + I2))) END DO END DO DO K = 1, VECLEN + -1, 2 DO J0 = 1, (NDIM3 + -5_8), 6 DO I0 = 1, NDIM2, 1 B(I0, J0, K) = DBLE(((K - I0) - J0)) B(I0, J0, K + 1) = DBLE((((K - I0) - J0) + 1)) B(I0, J0 + 1, K) = DBLE(((K - I0) -(J0 + 1))) B(I0, J0 + 1, K + 1) = DBLE((((K - I0) -(J0 + 1)) + 1)) B(I0, J0 + 2, K) = DBLE(((K - I0) -(J0 + 2))) B(I0, J0 + 2, K + 1) = DBLE((((K - I0) -(J0 + 2)) + 1)) B(I0, J0 + 3, K) = DBLE(((K - I0) -(J0 + 3))) B(I0, J0 + 3, K + 1) = DBLE((((K - I0) -(J0 + 3)) + 1)) B(I0, J0 + 4, K) = DBLE(((K - I0) -(J0 + 4))) B(I0, J0 + 4, K + 1) = DBLE((((K - I0) -(J0 + 4)) + 1)) B(I0, J0 + 5, K) = DBLE(((K - I0) -(J0 + 5))) B(I0, J0 + 5, K + 1) = DBLE((((K - I0) -(J0 + 5)) + 1)) END DO END DO DO wd_J1 = J0, NDIM3 + -1, 2 DO I3 = 1, NDIM2, 1 B(I3, wd_J1, K) = DBLE(((K - I3) - wd_J1)) B(I3, wd_J1, K + 1) = DBLE((((K - I3) - wd_J1) + 1)) B(I3, wd_J1 + 1, K) = DBLE(((K - I3) -(wd_J1 + 1))) B(I3, wd_J1 + 1, K + 1) = DBLE((((K - I3) -(wd_J1 + 1)) + 1)) END DO END DO DO wd_$wd_J1 = wd_J1, NDIM3, 1 DO I4 = 1, NDIM2, 1 B(I4, wd_$wd_J1, K) = DBLE(((K - I4) - wd_$wd_J1)) B(I4, wd_$wd_J1, K + 1) = DBLE((((K - I4) - wd_$wd_J1) + 1)) END DO END DO END DO DO wd_K = K, VECLEN, 1 DO J1 = 1, (NDIM3 + -5_8), 6 DO I5 = 1, NDIM2, 1 B(I5, J1, wd_K) = DBLE(((wd_K - I5) - J1)) B(I5, J1 + 1, wd_K) = DBLE(((wd_K - I5) -(J1 + 1))) B(I5, J1 + 2, wd_K) = DBLE(((wd_K - I5) -(J1 + 2))) B(I5, J1 + 3, wd_K) = DBLE(((wd_K - I5) -(J1 + 3))) B(I5, J1 + 4, wd_K) = DBLE(((wd_K - I5) -(J1 + 4))) B(I5, J1 + 5, wd_K) = DBLE(((wd_K - I5) -(J1 + 5))) END DO END DO DO wd_J0 = J1, NDIM3 + -1, 2 DO I6 = 1, NDIM2, 1 B(I6, wd_J0, wd_K) = DBLE(((wd_K - I6) - wd_J0)) B(I6, wd_J0 + 1, wd_K) = DBLE(((wd_K - I6) -(wd_J0 + 1))) END DO END DO DO wd_$wd_J0 = wd_J0, NDIM3, 1 DO I7 = 1, NDIM2, 1 B(I7, wd_$wd_J0, wd_K) = DBLE(((wd_K - I7) - wd_$wd_J0)) END DO END DO END DO RETURN END SUBROUTINE SUBROUTINE diff2(N, C, D, DIFF) IMPLICIT NONE INTEGER(4) N REAL(8) C(t$18) REAL(8) D(t$18) REAL(8) DIFF C C **** Variables and functions **** C INTEGER(8) t$18 INTEGER(8) t$19 INTEGER(4) I C C **** statements **** C t$18 = N t$19 = MAX(N, 0) DIFF = 0.0D00 DO I = 1, N, 1 DIFF = (DIFF +(((C(I) - D(I))) ** 2)) END DO RETURN END SUBROUTINE SUBROUTINE method1(NDIM1, NDIM2, NDIM3, VECLEN, A, B, C) IMPLICIT NONE INTEGER(4) NDIM1 INTEGER(4) NDIM2 INTEGER(4) NDIM3 INTEGER(4) VECLEN REAL(8) A((t$21) - -1_8, (t$22) - -1_8) REAL(8) B((t$23) - -1_8, (t$22) - -1_8, (t$24) - -1_8) REAL(8) C((t$23) - -1_8, (t$21) - -1_8, (t$24) - -1_8) C C **** Variables and functions **** C INTEGER(8) t$21 INTEGER(8) t$26 INTEGER(8) t$22 INTEGER(8) t$29 INTEGER(8) t$23 INTEGER(8) t$32 INTEGER(8) t$24 INTEGER(8) t$36 INTEGER(4) I INTEGER(4) N1 INTEGER(4) N2 INTEGER(4) N3 INTEGER(8) t$25 INTEGER(8) t$27 INTEGER(8) t$28 INTEGER(8) t$30 INTEGER(8) t$31 INTEGER(8) t$33 INTEGER(8) t$34 INTEGER(8) t$35 INTEGER(8) t$37 INTEGER(8) t$38 INTEGER(8) t$39 C C **** Temporary variables **** C REAL(8) mi0 C C **** statements **** C t$21 = INT8((NDIM1 + -1)) t$22 = INT8((NDIM3 + -1)) t$25 = (INT8((NDIM1 + -1)) + 1) t$26 = MAX((INT8((NDIM1 + -1)) + 1), 0) t$27 = (MAX((INT8((NDIM1 + -1)) + 1), 0) * 2) t$28 = (INT8((NDIM3 + -1)) + 1) t$29 = MAX((INT8((NDIM3 + -1)) + 1), 0) t$30 = (MAX((INT8((NDIM1 + -1)) + 1), 0) * MAX((INT8((NDIM3 + -1)) + 1), 0)) t$23 = INT8((NDIM2 + -1)) t$24 = INT8((VECLEN + -1)) t$31 = (INT8((NDIM2 + -1)) + 1) t$32 = MAX((INT8((NDIM2 + -1)) + 1), 0) t$33 = (MAX((INT8((NDIM2 + -1)) + 1), 0) * 2) t$34 = ((MAX((INT8((NDIM2 + -1)) + 1), 0) * MAX((INT8((NDIM3 + -1)) + 1), 0)) * 2) t$35 = (INT8((VECLEN + -1)) + 1) t$36 = MAX((INT8((VECLEN + -1)) + 1), 0) t$37 = (MAX((INT8((NDIM2 + -1)) + 1), 0) *(MAX((INT8((NDIM3 + -1)) + 1), 0) * MAX((INT8((VECLEN + -1)) + 1), 0))) t$38 = ((MAX((INT8((NDIM1 + -1)) + 1), 0) * MAX((INT8((NDIM2 + -1)) + 1), 0)) * 2) t$39 = (MAX((INT8((NDIM2 + -1)) + 1), 0) *(MAX((INT8((NDIM1 + -1)) + 1), 0) * MAX((INT8((VECLEN + -1)) + 1), 0))) IF(NDIM2 .GE. 1) THEN DO I = 0, VECLEN + -1, 1 DO N3 = 0, NDIM3 + -1, 1 DO N1 = 0, NDIM1 + -1, 1 mi0 = A(N1 + 1, N3 + 1) DO N2 = 0, NDIM2 + -1, 1 C(N2 + 1, N1 + 1, I + 1) = (C(N2 + 1, N1 + 1, I + 1) +(B(N2 + 1, N3 + 1, I + 1) * mi0)) END DO END DO END DO END DO ENDIF RETURN END SUBROUTINE SUBROUTINE method2(NDIM1, NDIM2, NDIM3, VECLEN, A, B, C) IMPLICIT NONE INTEGER(4) NDIM1 INTEGER(4) NDIM2 INTEGER(4) NDIM3 INTEGER(4) VECLEN REAL(8) A(t$40, t$41) REAL(8) B(t$42, t$41, t$43) REAL(8) C(t$42, t$40, t$43) C C **** Variables and functions **** C INTEGER(8) t$40 INTEGER(8) t$44 INTEGER(8) t$41 INTEGER(8) t$46 INTEGER(8) t$42 INTEGER(8) t$48 INTEGER(8) t$43 INTEGER(8) t$51 INTEGER(4) I INTEGER(4) N1 INTEGER(4) N2 INTEGER(4) N3 INTEGER(8) t$45 INTEGER(8) t$47 INTEGER(8) t$49 INTEGER(8) t$50 INTEGER(8) t$52 INTEGER(8) t$53 INTEGER(8) t$54 C C **** Temporary variables **** C REAL(8) mi1 REAL(8) mi2 REAL(8) mi3 REAL(8) mi4 REAL(8) mi5 REAL(8) mi6 REAL(8) mi7 REAL(8) mi8 REAL(8) mi9 REAL(8) mi10 REAL(8) mi11 REAL(8) mi12 REAL(8) mi13 REAL(8) mi14 REAL(8) mi15 REAL(8) mi16 INTEGER(4) wd_N REAL(8) mi17 REAL(8) mi18 REAL(8) mi19 REAL(8) mi20 INTEGER(4) N0 INTEGER(4) wd_N3 INTEGER(4) N REAL(8) mi21 REAL(8) mi22 REAL(8) mi23 REAL(8) mi24 INTEGER(4) N4 INTEGER(4) wd_N1 REAL(8) mi25 INTEGER(4) N5 C C **** statements **** C t$40 = NDIM1 t$41 = NDIM3 t$44 = MAX(NDIM1, 0) t$45 = (MAX(NDIM1, 0) * 2) t$46 = MAX(NDIM3, 0) t$47 = (MAX(NDIM1, 0) * MAX(NDIM3, 0)) t$42 = NDIM2 t$43 = VECLEN t$48 = MAX(NDIM2, 0) t$49 = (MAX(NDIM2, 0) * 2) t$50 = ((MAX(NDIM2, 0) * MAX(NDIM3, 0)) * 2) t$51 = MAX(VECLEN, 0) t$52 = (MAX(NDIM2, 0) *(MAX(NDIM3, 0) * MAX(VECLEN, 0))) t$53 = ((MAX(NDIM1, 0) * MAX(NDIM2, 0)) * 2) t$54 = (MAX(NDIM2, 0) *(MAX(NDIM1, 0) * MAX(VECLEN, 0))) DO I = 1, VECLEN, 1 DO N3 = 1, (NDIM3 + -3_8), 4 DO N1 = 1, (NDIM1 + -3_8), 4 IF(NDIM2 .GE. 1) THEN mi1 = A(N1, N3) mi2 = A(N1 + 3, N3 + 3) mi3 = A(N1 + 3, N3 + 2) mi4 = A(N1 + 3, N3 + 1) mi5 = A(N1 + 3, N3) mi6 = A(N1, N3 + 1) mi7 = A(N1 + 2, N3 + 3) mi8 = A(N1 + 2, N3 + 2) mi9 = A(N1 + 2, N3 + 1) mi10 = A(N1 + 2, N3) mi11 = A(N1, N3 + 2) mi12 = A(N1 + 1, N3 + 3) mi13 = A(N1 + 1, N3 + 2) mi14 = A(N1 + 1, N3 + 1) mi15 = A(N1 + 1, N3) mi16 = A(N1, N3 + 3) DO N2 = 1, NDIM2, 1 C(N2, N1, I) = (C(N2, N1, I) +(B(N2, N3, I) * mi1)) C(N2, N1, I) = (C(N2, N1, I) +(B(N2, N3 + 1, I) * mi6)) C(N2, N1, I) = (C(N2, N1, I) +(B(N2, N3 + 2, I) * mi11)) C(N2, N1, I) = (C(N2, N1, I) +(B(N2, N3 + 3, I) * mi16)) C(N2, N1 + 1, I) = (C(N2, N1 + 1, I) +(B(N2, N3, I) * mi15)) C(N2, N1 + 1, I) = (C(N2, N1 + 1, I) +(B(N2, N3 + 1, I) * mi14)) C(N2, N1 + 1, I) = (C(N2, N1 + 1, I) +(B(N2, N3 + 2, I) * mi13)) C(N2, N1 + 1, I) = (C(N2, N1 + 1, I) +(B(N2, N3 + 3, I) * mi12)) C(N2, N1 + 2, I) = (C(N2, N1 + 2, I) +(B(N2, N3, I) * mi10)) C(N2, N1 + 2, I) = (C(N2, N1 + 2, I) +(B(N2, N3 + 1, I) * mi9)) C(N2, N1 + 2, I) = (C(N2, N1 + 2, I) +(B(N2, N3 + 2, I) * mi8)) C(N2, N1 + 2, I) = (C(N2, N1 + 2, I) +(B(N2, N3 + 3, I) * mi7)) C(N2, N1 + 3, I) = (C(N2, N1 + 3, I) +(B(N2, N3, I) * mi5)) C(N2, N1 + 3, I) = (C(N2, N1 + 3, I) +(B(N2, N3 + 1, I) * mi4)) C(N2, N1 + 3, I) = (C(N2, N1 + 3, I) +(B(N2, N3 + 2, I) * mi3)) C(N2, N1 + 3, I) = (C(N2, N1 + 3, I) +(B(N2, N3 + 3, I) * mi2)) END DO ENDIF END DO IF(NDIM2 .GE. 1) THEN DO wd_N = N1, NDIM1, 1 mi17 = A(wd_N, N3) mi18 = A(wd_N, N3 + 1) mi19 = A(wd_N, N3 + 3) mi20 = A(wd_N, N3 + 2) DO N0 = 1, NDIM2, 1 C(N0, wd_N, I) = (C(N0, wd_N, I) +(B(N0, N3, I) * mi17)) C(N0, wd_N, I) = (C(N0, wd_N, I) +(B(N0, N3 + 1, I) * mi18)) C(N0, wd_N, I) = (C(N0, wd_N, I) +(B(N0, N3 + 2, I) * mi20)) C(N0, wd_N, I) = (C(N0, wd_N, I) +(B(N0, N3 + 3, I) * mi19)) END DO END DO ENDIF END DO DO wd_N3 = N3, NDIM3, 1 DO N = 1, (NDIM1 + -3_8), 4 IF(NDIM2 .GE. 1) THEN mi21 = A(N, wd_N3) mi22 = A(N + 3, wd_N3) mi23 = A(N + 1, wd_N3) mi24 = A(N + 2, wd_N3) DO N4 = 1, NDIM2, 1 C(N4, N, I) = (C(N4, N, I) +(B(N4, wd_N3, I) * mi21)) C(N4, N + 1, I) = (C(N4, N + 1, I) +(B(N4, wd_N3, I) * mi23)) C(N4, N + 2, I) = (C(N4, N + 2, I) +(B(N4, wd_N3, I) * mi24)) C(N4, N + 3, I) = (C(N4, N + 3, I) +(B(N4, wd_N3, I) * mi22)) END DO ENDIF END DO IF(NDIM2 .GE. 1) THEN DO wd_N1 = N, NDIM1, 1 mi25 = A(wd_N1, wd_N3) DO N5 = 1, NDIM2, 1 C(N5, wd_N1, I) = (C(N5, wd_N1, I) +(B(N5, wd_N3, I) * mi25)) END DO END DO ENDIF END DO END DO RETURN END SUBROUTINE --------------BD45B233F9A79E5864027759-- From owner-pro64-support@oss.sgi.com Wed May 9 03:53:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f49Arp420125 for pro64-support-outgoing; Wed, 9 May 2001 03:53:51 -0700 Received: from probity.mcc.ac.uk (probity.mcc.ac.uk [130.88.200.94]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49AroF20122 for ; Wed, 9 May 2001 03:53:50 -0700 Received: from wallace.mvc.mcc.ac.uk ([130.88.1.130] helo=man.ac.uk) by probity.mcc.ac.uk with esmtp (Exim 2.05 #4) id 14xRbD-000G9N-00; Wed, 9 May 2001 11:53:43 +0100 Message-ID: <3AF92214.605C9B76@man.ac.uk> Date: Wed, 09 May 2001 11:55:16 +0100 From: Dan Kidger Organization: Manchester Computing X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Nelson H. F. Beebe" CC: Stephen Pickles , Pro64 Support Subject: Re: fortran performance and array indexing References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pro64-support@oss.sgi.com Precedence: bulk "Nelson H. F. Beebe" wrote: > Compaq AlphaServer ES40 Sierra/667 (32 EV6.7 21264A CPUs, 667 MHz, 8GB RAM); OSF/1 5.0 > f95 -O5 matmul_test.f && ./a.out > speed(1) = 84.92637 > speed(2) = 86.62321 > discrepancy = 0.000000000000000E+000 hmm I get different figures to you here. I get on the same hardware (ES40 = 4x 667Mhz Alpha EV6.7 with 4Gb RAM): f90 -O5 matmul_test.f -o matmul_test.kelvin && ./matmul_test.kelvin speed(1) = 172.9608 speed(2) = 103.7560 discrepancy = 0.000000000000000E+000 but: f90 -O3 matmul_test.f -o matmul_test.kelvin && ./matmul_test.kelvin speed(1) = 235.6120 speed(2) = 234.7684 discrepancy = 0.000000000000000E+000 so here is certainly one case where aggressive optimisation makes things worse. Also to add to your figures, on the Cray T3E: (816x 600Mhz Alpha EV6 with 256Mb memory): f90 -O3 matmul_test.f -o matmul_test.turing && ./matmul_test.turing speed(1) = 59.99571143155223 speed(2) = 61.396552312259679 discrepancy = 0.E+0 and on the the Sgi Origin 3000 (256x 400Mhz Mips 12k , IRIX 6.5.11f, MIPSpro Compilers: Version 7.3.1.1m): f90 -O3 matmul_test.f -o matmul_test.green && ./matmul_test.green speed(1) = 200.609299 speed(2) = 220.491638 discrepancy = 0.E+0 and on the SGI Troons (2x 667Mhz IA64 with 2Gb RAM): Finally is it worth checking the memory alignment of arrays in cases where the first element is *not* A(1:1) ? Yours, Daniel ----------------------------------------------------------------------- Dr. Daniel Kidger | E: d.kidger@man.ac.uk High Performance Computing Group | W: www.csar.cfs.ac.uk Manchester Computing, University of Manchester, | T: +44 161 275 7038 Oxford Road, Manchester, M13 9PL, UK | F: +44 161 275 6800 --------------------Q: what's up ? A: X cross Z --------------------- From owner-pro64-support@oss.sgi.com Wed May 9 07:09:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f49E9uo28120 for pro64-support-outgoing; Wed, 9 May 2001 07:09:56 -0700 Received: from mail.eecis.udel.edu (louie.udel.edu [128.175.2.33]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f49E9tF28117 for ; Wed, 9 May 2001 07:09:55 -0700 Received: from louie.udel.edu by mail.eecis.udel.edu id aa03342; 9 May 2001 10:08 EDT Date: Wed, 9 May 2001 10:08:02 -0400 (EDT) From: Haiping Wu To: pro64-support@oss.sgi.com MMDF-Warning: Parse error in original version of preceding line at mail.eecis.udel.edu Subject: How can pro64 generate code without GP register? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pro64-support@oss.sgi.com Precedence: bulk From owner-pro64-support@oss.sgi.com Wed May 9 07:39:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f49Ed3B30107 for pro64-support-outgoing; Wed, 9 May 2001 07:39:03 -0700 Received: from osc.edu (osc.edu [192.148.249.4]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49Ed2F30104 for ; Wed, 9 May 2001 07:39:02 -0700 Received: from neptune.osc.edu (IDENT:djohnson@neptune.osc.edu [192.148.249.73]) by osc.edu (8.9.3/8.9.3/OSC 2.0) with ESMTP id KAA00655; Wed, 9 May 2001 10:38:57 -0400 (EDT) Date: Wed, 9 May 2001 10:38:57 -0400 (EDT) From: Douglas Johnson X-Sender: djohnson@localhost.localdomain To: Haiping Wu cc: pro64-support@oss.sgi.com Subject: Re: How can pro64 generate code without GP register? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Pass -mconstant-gp to the assembler, ie, -Wla,-mconstant-gp Doug From owner-pro64-support@oss.sgi.com Wed May 9 11:27:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f49IRS603539 for pro64-support-outgoing; Wed, 9 May 2001 11:27:28 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49IRSF03536 for ; Wed, 9 May 2001 11:27:28 -0700 Received: from rohi.engr.sgi.com (rohi.engr.sgi.com [130.62.180.74]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id LAA06497 for ; Wed, 9 May 2001 11:38:18 -0700 (PDT) mail_from (mpm@rohi.engr.sgi.com) Received: (from mpm@localhost) by rohi.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id LAA54640; Wed, 9 May 2001 11:22:45 -0700 (PDT) Date: Wed, 9 May 2001 11:22:45 -0700 (PDT) From: mpm@rohi.engr.sgi.com (Michael Murphy) Message-Id: <200105091822.LAA54640@rohi.engr.sgi.com> To: Haiping Wu , Douglas Johnson Subject: Re: How can pro64 generate code without GP register? Cc: pro64-support@oss.sgi.com Sender: owner-pro64-support@oss.sgi.com Precedence: bulk From: Douglas Johnson Subject: Re: How can pro64 generate code without GP register? Pass -mconstant-gp to the assembler, ie, -Wla,-mconstant-gp No. First of all, -mconstant-gp needs to be passed to the back-end (sgicc accepts -mconstant-gp), not just the assembler and linker. But even still, GP will be used, it just won't be saved and restored. The option means that the GP is not changed, not that it isn't used. There is no option to not use GP at all. -- Mike Murphy -- mpm@sgi.com -- quote of the day: -- "Blessed is he who has learned to laugh at himself, -- for he shall never cease to be entertained." (John Boswell) From owner-pro64-support@oss.sgi.com Wed May 9 12:37:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f49JbVU07515 for pro64-support-outgoing; Wed, 9 May 2001 12:37:31 -0700 Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49JbUF07512 for ; Wed, 9 May 2001 12:37:30 -0700 Received: from apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.9.3/8.9.3) with ESMTP id MAA10235 for ; Wed, 9 May 2001 12:37:29 -0700 (PDT) From: stuart@apple.com Received: from scv3.apple.com (scv3.apple.com) by apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Wed, 9 May 2001 12:37:28 -0700 Received: from peugot (peugot.apple.com [17.202.41.43]) by scv3.apple.com (8.9.3/8.9.3) with ESMTP id MAA16065 for ; Wed, 9 May 2001 12:37:28 -0700 (PDT) Message-Id: <200105091937.MAA16065@scv3.apple.com> Date: Wed, 9 May 2001 12:37:28 -0700 Content-Type: text/plain; format=flowed; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v387) To: pro64-support@oss.sgi.com X-Mailer: Apple Mail (2.387) Content-Transfer-Encoding: 7bit Subject: unoptimized dead store Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Clueless newbie here. Here's my test program: ---------------------- int a, b ; main( int xx) { a = 2 ; glarp( xx) ; a++ ; return a + b ; } glarp( int j) { extern int a ; if (j < 10) bling( j-1) ; } bling( int k) { extern int b ; b = k ; } ---------------------- Here's my commandline: % sgicc -O3 -IPA:inline=no -v -o test test.c >& log ; objdump -S test > test.dump ; more test.dump I'm running this on a RedHat x86 box with NUE 1.0. My SGICC describes itself thusly: % sgicc -v SGIcc Compilers: Version 0.01.0-13 Here's my question: I believe the store "a = 2" is dead, and that the SGICC Interprocedural Analyzer should be able to discern this. If I allow SGICC to use inlining (replace "-IPA:inline=no" with "-IPA"), this store disappears. But then the deletion of this store isn't an "interprocedural" optimization anymore :-) . What am I missing? Why doesn't SGICC delete this store? Thanks in advance, stuart hastings From owner-pro64-support@oss.sgi.com Wed May 9 13:10:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f49KA4o08290 for pro64-support-outgoing; Wed, 9 May 2001 13:10:04 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49KA4F08286 for ; Wed, 9 May 2001 13:10:04 -0700 Received: from harpoon.engr.sgi.com (harpoon.engr.sgi.com [130.62.41.49]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id NAA07363 for ; Wed, 9 May 2001 13:20:54 -0700 (PDT) mail_from (jkingdon@cthulhu.engr.sgi.com) Received: from engr.sgi.com (kingdon.engr.sgi.com [130.62.180.80]) by harpoon.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id NAA97939; Wed, 9 May 2001 13:08:46 -0700 (PDT) Message-ID: <3AF9A3DE.FE3498A3@engr.sgi.com> Date: Wed, 09 May 2001 13:09:02 -0700 From: Jim Kingdon X-Mailer: Mozilla 4.7C-SGI [en] (X11; I; IRIX 6.5 IP32) X-Accept-Language: en MIME-Version: 1.0 To: stuart@apple.com, pro64-support@oss.sgi.com Subject: Re: unoptimized dead store References: <200105091937.MAA16065@scv3.apple.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Looks interprocedural to me. The optimization is only possible if the compiler knows that the "glarp" function does not modify "a". (Look up "alias" in a compiler text, "restrict" in C99, similar rules for Fortran, &c). stuart@apple.com wrote: > Clueless newbie here. > > Here's my test program: > ---------------------- > int a, b ; > > main( int xx) > { > a = 2 ; > glarp( xx) ; > a++ ; > return a + b ; > } > glarp( int j) > { > extern int a ; > > if (j < 10) > bling( j-1) ; > } > > bling( int k) > { > extern int b ; > > b = k ; > } From owner-pro64-support@oss.sgi.com Wed May 9 13:23:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f49KN9L08553 for pro64-support-outgoing; Wed, 9 May 2001 13:23:09 -0700 Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49KN9F08550 for ; Wed, 9 May 2001 13:23:09 -0700 Received: from SMTP (fmsmsxvs01-1.fm.intel.com [132.233.42.201]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.38 2001/05/09 12:49:45 root Exp $) with SMTP id UAA24443; Wed, 9 May 2001 20:22:58 GMT Received: from fmsmsx27.FM.INTEL.COM ([132.233.48.27]) by 132.233.48.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 09 May 2001 20:15:23 0000 (GMT) Received: by fmsmsx27.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 9 May 2001 13:15:22 -0700 Message-ID: <9287DC1579B0D411AA2F009027F44C3F042DFA99@FMSMSX41> From: "Chan, Sun C" To: "'Jim Kingdon'" , stuart@apple.com, pro64-support@oss.sgi.com Subject: RE: unoptimized dead store Date: Wed, 9 May 2001 13:15:20 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Actually xx is uninitialized, so value returned by main could be anything. (BTW, I didn't see the original posting on what is the problem.) Sun > -----Original Message----- From: Jim Kingdon [mailto:jkingdon@cthulhu.engr.sgi.com] Sent: Wednesday, May 09, 2001 1:09 PM > To: stuart@apple.com; pro64-support@oss.sgi.com Subject: Re: unoptimized dead store Looks > interprocedural to me. The optimization > is only possible if the compiler knows that > the "glarp" function does not modify "a". > > (Look up "alias" in a compiler text, "restrict" > in C99, similar rules for Fortran, &c). > > stuart@apple.com wrote: > > > Clueless newbie here. > > > > Here's my test program: > > ---------------------- > > int a, b ; > > > > main( int xx) > > { > > a = 2 ; > > glarp( xx) ; > > a++ ; > > return a + b ; > > } > > glarp( int j) > > { > > extern int a ; > > > > if (j < 10) > > bling( j-1) ; > > } > > > > bling( int k) > > { > > extern int b ; > > > > b = k ; > > } > From owner-pro64-support@oss.sgi.com Wed May 9 13:37:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f49Kb7908929 for pro64-support-outgoing; Wed, 9 May 2001 13:37:07 -0700 Received: from mail-in.hq.tensilica.com (hq.tensilica.com [38.170.141.29]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49Kb6F08926 for ; Wed, 9 May 2001 13:37:06 -0700 Received: from bigbird.hq.tensilica.com (IDENT:robert@bigbird.hq.tensilica.com [192.168.10.142]) by mail-in.hq.tensilica.com (8.9.3/8.9.3) with ESMTP id NAA02390; Wed, 9 May 2001 13:36:58 -0700 Date: Wed, 9 May 2001 13:36:58 -0700 Message-Id: <200105092036.NAA02390@mail-in.hq.tensilica.com> From: Robert Kennedy To: sun.c.chan@intel.com CC: jkingdon@cthulhu.engr.sgi.com, stuart@apple.com, pro64-support@oss.sgi.com In-reply-to: <9287DC1579B0D411AA2F009027F44C3F042DFA99@FMSMSX41> (sun.c.chan@intel.com) Subject: Re: unoptimized dead store References: <9287DC1579B0D411AA2F009027F44C3F042DFA99@FMSMSX41> Sender: owner-pro64-support@oss.sgi.com Precedence: bulk > Actually xx is uninitialized, so value returned by main could > be anything. I'm confused. xx is initialized; it's argc. -- Robert From owner-pro64-support@oss.sgi.com Wed May 9 13:44:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f49KiIG09153 for pro64-support-outgoing; Wed, 9 May 2001 13:44:18 -0700 Received: from mail-in.hq.tensilica.com (hq.tensilica.com [38.170.141.29]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49KiHF09150 for ; Wed, 9 May 2001 13:44:17 -0700 Received: from bigbird.hq.tensilica.com (IDENT:robert@bigbird.hq.tensilica.com [192.168.10.142]) by mail-in.hq.tensilica.com (8.9.3/8.9.3) with ESMTP id NAA08170; Wed, 9 May 2001 13:44:05 -0700 Date: Wed, 9 May 2001 13:44:05 -0700 Message-Id: <200105092044.NAA08170@mail-in.hq.tensilica.com> From: Robert Kennedy To: stuart@apple.com CC: pro64-support@oss.sgi.com In-reply-to: <200105091937.MAA16065@scv3.apple.com> (stuart@apple.com) Subject: Re: unoptimized dead store References: <200105091937.MAA16065@scv3.apple.com> Sender: owner-pro64-support@oss.sgi.com Precedence: bulk > I believe the store "a = 2" is dead, and that the SGICC > Interprocedural Analyzer should be able to discern this. The store isn't dead. It's value is used by the "a++" statement after the "glarp" call. If glarp is inlined, the optimizer is able to see that "a++" is equivalent to a = 3 because there's nothing in between that might alter the variable a. That equivalence is what allows the initial "a = 2" to be deleted. If glarp isn't inlined, apparently the optimizer isn't getting enough information from IPA to be sure that a isn't modified by glarp. I haven't looked at what's happening exactly -- it could be a number of different things. But it's going to come down to the fact that when the inlining happens, the optimizer can see more detail than IPA will tell it when no inlining is allowed. -- Robert From owner-pro64-support@oss.sgi.com Wed May 9 13:56:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f49KuDT09406 for pro64-support-outgoing; Wed, 9 May 2001 13:56:13 -0700 Received: from web3504.mail.yahoo.com (web3504.mail.yahoo.com [204.71.203.71]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f49KuDF09403 for ; Wed, 9 May 2001 13:56:13 -0700 Message-ID: <20010509205613.27993.qmail@web3504.mail.yahoo.com> Received: from [15.255.208.34] by web3504.mail.yahoo.com; Wed, 09 May 2001 13:56:13 PDT Date: Wed, 9 May 2001 13:56:13 -0700 (PDT) From: Shin-Ming Liu Subject: Re: unoptimized dead store To: Robert Kennedy , stuart@apple.com Cc: pro64-support@oss.sgi.com In-Reply-To: <200105092044.NAA08170@mail-in.hq.tensilica.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-pro64-support@oss.sgi.com Precedence: bulk If the mod/ref analysis in IPA concludes the variable a is not modified in the function glarp, the optimizer could still conclude the value of "a++" and dead code eliminate the store "a = 2". --- Robert Kennedy wrote: > > I believe the store "a = 2" is dead, and that the > SGICC > > Interprocedural Analyzer should be able to discern > this. > > The store isn't dead. It's value is used by the > "a++" statement after > the "glarp" call. > > If glarp is inlined, the optimizer is able to see > that "a++" is > equivalent to a = 3 because there's nothing in > between that might > alter the variable a. That equivalence is what > allows the initial "a = > 2" to be deleted. > > If glarp isn't inlined, apparently the optimizer > isn't getting enough > information from IPA to be sure that a isn't > modified by glarp. I > haven't looked at what's happening exactly -- it > could be a number of > different things. But it's going to come down to the > fact that when > the inlining happens, the optimizer can see more > detail than IPA will > tell it when no inlining is allowed. > > -- Robert > __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ From owner-pro64-support@oss.sgi.com Wed May 9 14:07:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f49L7oi10160 for pro64-support-outgoing; Wed, 9 May 2001 14:07:50 -0700 Received: from mail-in.hq.tensilica.com (hq.tensilica.com [38.170.141.29]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49L7oF10156 for ; Wed, 9 May 2001 14:07:50 -0700 Received: from bigbird.hq.tensilica.com (IDENT:robert@bigbird.hq.tensilica.com [192.168.10.142]) by mail-in.hq.tensilica.com (8.9.3/8.9.3) with ESMTP id OAA19380; Wed, 9 May 2001 14:07:47 -0700 Date: Wed, 9 May 2001 14:07:47 -0700 Message-Id: <200105092107.OAA19380@mail-in.hq.tensilica.com> From: Robert Kennedy To: shinmingliu@yahoo.com CC: stuart@apple.com, pro64-support@oss.sgi.com In-reply-to: <20010509205613.27993.qmail@web3504.mail.yahoo.com> (message from Shin-Ming Liu on Wed, 9 May 2001 13:56:13 -0700 (PDT)) Subject: Re: unoptimized dead store References: <20010509205613.27993.qmail@web3504.mail.yahoo.com> Sender: owner-pro64-support@oss.sgi.com Precedence: bulk > If the mod/ref analysis in IPA concludes the variable > a is not modified in the function glarp, the optimizer > could still conclude the value of "a++" and dead > code eliminate the store "a = 2". Definitely true, but obviously that isn't happening in this example. Like I said, I haven't analyzed it so I have no information about why it isn't happening. The two main possibilities are that the info from IPA is too conservative, or that the optimizer's overly conservative vsym assignment is responsible (my first guess is that the glarp call has a chi for the return vsym, and "a" also aliases with the return vsym). If it is the latter possibility, it would take fairly major changes to fix it. -- Robert From owner-pro64-support@oss.sgi.com Wed May 9 23:34:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4A6YD423963 for pro64-support-outgoing; Wed, 9 May 2001 23:34:13 -0700 Received: from hebe.or.intel.com (jffdns02.or.intel.com [134.134.248.4]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4A6YCF23960 for ; Wed, 9 May 2001 23:34:12 -0700 Received: from SMTP (orsmsxvs01-1.jf.intel.com [192.168.65.200]) by hebe.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.38 2001/05/09 12:49:45 root Exp $) with SMTP id GAA19045; Thu, 10 May 2001 06:33:57 GMT Received: from orsmsx29.jf.intel.com ([192.168.70.29]) by 192.168.70.200 (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 10 May 2001 06:30:16 0000 (GMT) Received: by orsmsx29.jf.intel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 9 May 2001 21:22:59 -0700 Message-ID: <9287DC1579B0D411AA2F009027F44C3F042DFA9C@FMSMSX41> From: "Chan, Sun C" To: "'Robert Kennedy'" , shinmingliu@yahoo.com Cc: stuart@apple.com, pro64-support@oss.sgi.com Subject: RE: unoptimized dead store Date: Wed, 9 May 2001 16:05:15 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-pro64-support@oss.sgi.com Precedence: bulk The other possibility is that since "a" is global, it could be modified by a shared library. If you mark "a" as static, the statement should go away. If not, it is back to your conjecture. BTW, thx for pointing out the obvious. Sun > -----Original Message----- > From: Robert Kennedy [mailto:robert@tensilica.com] > Sent: Wednesday, May 09, 2001 2:08 PM > To: shinmingliu@yahoo.com > Cc: stuart@apple.com; pro64-support@oss.sgi.com > Subject: Re: unoptimized dead store > > > > If the mod/ref analysis in IPA concludes the variable > > a is not modified in the function glarp, the optimizer > > could still conclude the value of "a++" and dead > > code eliminate the store "a = 2". > > Definitely true, but obviously that isn't happening in this > example. Like I said, I haven't analyzed it so I have no information > about why it isn't happening. The two main possibilities are that the > info from IPA is too conservative, or that the optimizer's overly > conservative vsym assignment is responsible (my first guess is that > the glarp call has a chi for the return vsym, and "a" also aliases > with the return vsym). If it is the latter possibility, it would take > fairly major changes to fix it. > > -- Robert > > From owner-pro64-support@oss.sgi.com Thu May 10 04:29:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4ABTFv31197 for pro64-support-outgoing; Thu, 10 May 2001 04:29:15 -0700 Received: from artemis.rus.uni-stuttgart.de (artemis.rus.uni-stuttgart.de [129.69.1.28]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4ABTBF31194 for ; Thu, 10 May 2001 04:29:11 -0700 Received: from baracke.rus.uni-stuttgart.de (baracke.rus.uni-stuttgart.de [129.69.58.100]) by artemis.rus.uni-stuttgart.de with ESMTP id NAA26005 for ; Thu, 10 May 2001 13:29:10 +0200 (MET DST) env-from (ruschelf@baracke.rus.uni-stuttgart.de) Received: (from ruschelf@localhost) by baracke.rus.uni-stuttgart.de (AIX4.3/UCB 8.8.8/8.8.8) id NAA54712 for pro64-support@oss.sgi.com; Thu, 10 May 2001 13:29:09 +0200 Date: Thu, 10 May 2001 13:29:09 +0200 From: Clemens Helf To: pro64-support@oss.sgi.com Subject: math library performance issue Message-ID: <20010510132909.D53846@baracke.rus.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Dear all, The function 'double pow (double x, double y)' (libmsgi.a) seems to have a severe performance problem. Substituting the call by 'exp(log(x)*y)' cuts down execution time by about one third. Annother question is related to vector math: Will the compiler substitute a call to e.g. 'exp(x)' by the corresponding vector math function after loop optimization ? Will the compiler adjust a call to a vector math function found in the source code when it does further loop optimization ? Clemens Helf RUS/HLRS e.g. loop orginal: struct data { double a[2]; }; data array[10000]; for (int i=0; i; Thu, 10 May 2001 09:32:30 -0700 Received: from apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id JAA13055 for ; Thu, 10 May 2001 09:32:27 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 10 May 2001 09:31:34 -0700 Received: from peugot (peugot.apple.com [17.202.41.43]) by scv2.apple.com (8.11.3/8.11.3) with ESMTP id f4AGVXp08972; Thu, 10 May 2001 09:31:33 -0700 (PDT) Message-Id: <200105101631.f4AGVXp08972@scv2.apple.com> Content-Transfer-Encoding: 7bit Date: Thu, 10 May 2001 09:31:32 -0700 Content-Type: text/plain; format=flowed; charset=us-ascii Subject: Re: unoptimized dead store Cc: Stuart Hastings , "'Robert Kennedy'" , shinmingliu@yahoo.com, pro64-support@oss.sgi.com To: "Chan, Sun C" X-Mailer: Apple Mail (2.387) In-Reply-To: <9287DC1579B0D411AA2F009027F44C3F042DFA9C@FMSMSX41> Mime-Version: 1.0 (Apple Message framework v387) From: Stuart Hastings Sender: owner-pro64-support@oss.sgi.com Precedence: bulk On Wednesday, May 9, 2001, at 04:05 PM, Chan, Sun C wrote: > The other possibility is that since "a" is global, it could be modified > by a shared library. If you mark "a" as static, the statement should go > away. If not, it is back to your conjecture. > BTW, thx for pointing out the obvious. > Sun O.K., if 'a' is declared static, then it is immune from tampering by a shared library. However, I was hoping that IPA would be able to tell that neither glarp() nor any of its callees reference variable 'a'. If a shared library was going to reference 'a', then glarp() or one of its callees would be invoking an external function somewhere; they don't, and IPA should know that. % sgicc -O3 -IPA:inline=no -v -o test test.c >& log ; objdump -S test > test.dump ; more test.dump Please recall the commandline; I have explicitly disabled the inliner. If I allow SGICC to inline everything, functions glarp() and bling() are inlined, their bodies disappear, and the store to 'a' is deleted. If SGICC was worried about a dynamic library referencing 'a', then why is it so bold to delete global functions glarp() and bling()? By the same reasoning, functions glarp() and bling() could be invoked by a dynamic library. The current test program is a simplified case; the original program was three different modules. If I split the program into three files, keep variable 'a' as a global, and allow SGICC to inline everything, functions glarp() and bling() still disappear, and so does the dead store to 'a'. By-the-way, declaring 'a' static in the given testcase makes no difference; SGICC still doesn't delete the store to 'a'. Is there anything I can do to allow IPA to delete this store? (Other than enabling the inliner :-) stuart hastings ----------------------------------------- int a, b ; main( int xx) { a = 2 ; glarp( xx) ; a++ ; return a + b ; } glarp( int j) { extern int a ; if (j < 10) bling( j-1) ; } bling( int k) { extern int b ; b = k ; } From owner-pro64-support@oss.sgi.com Thu May 10 10:06:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4AH61v06184 for pro64-support-outgoing; Thu, 10 May 2001 10:06:01 -0700 Received: from mail-in.hq.tensilica.com (hq.tensilica.com [38.170.141.29]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4AH61F06181 for ; Thu, 10 May 2001 10:06:01 -0700 Received: from bigbird.hq.tensilica.com (IDENT:robert@bigbird.hq.tensilica.com [192.168.10.142]) by mail-in.hq.tensilica.com (8.9.3/8.9.3) with ESMTP id KAA09010; Thu, 10 May 2001 10:05:59 -0700 Date: Thu, 10 May 2001 10:05:59 -0700 Message-Id: <200105101705.KAA09010@mail-in.hq.tensilica.com> From: Robert Kennedy To: stuart@apple.com CC: sun.c.chan@intel.com, stuart@apple.com, shinmingliu@yahoo.com, pro64-support@oss.sgi.com In-reply-to: <200105101631.f4AGVXp08972@scv2.apple.com> (message from Stuart Hastings on Thu, 10 May 2001 09:31:32 -0700) Subject: Re: unoptimized dead store References: <200105101631.f4AGVXp08972@scv2.apple.com> Sender: owner-pro64-support@oss.sgi.com Precedence: bulk > O.K., if 'a' is declared static, then it is immune from tampering by a > shared library. However, I was hoping that IPA would be able to tell > that neither glarp() nor any of its callees reference variable 'a'. If a > shared library was going to reference 'a', then glarp() or one of its > callees would be invoking an external function somewhere; they don't, > and IPA should know that. And I think IPA does know that. I still conjecture that the problem is that the optimizer has no way (with the present infrastructure) to represent the info it gets from IPA in full detail. When there is no inlining, the glarp() call *MUST* be marked as possibly modifying the return vsym (because glarp() calls bling() which changes b, which is state that persists across the return from main() and is visible outside main()). Furthermore, since a is also a part of persistent state visible after main() returns, a will alias with the return vsym(). Since the optimizer represents the virtual variables this way, it cannot assume that the glarp() call does not use the value of a. This, I believe, is why the "a = 2" assignment doesn't get deleted when no inlining occurs. With inlining, there are no calls and the optimizer can see everything. In that case it does the right thing. > Is there anything I can do to allow IPA to delete this store? (Other > than enabling the inliner :-) IPA will never delete the store. The optimizer will delete it if anyone does. If my conjecture is right, you need to make "a" something that won't alias with the return vsym; in other words, you need to make "a" some sort of variable that the optimizer knows will not be used or modified after main()'s return. -- Robert From owner-pro64-support@oss.sgi.com Thu May 10 10:14:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4AHEee06536 for pro64-support-outgoing; Thu, 10 May 2001 10:14:40 -0700 Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4AHEdF06531 for ; Thu, 10 May 2001 10:14:39 -0700 Received: from SMTP (fmsmsxvs01-1.fm.intel.com [132.233.42.201]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.38 2001/05/09 12:49:45 root Exp $) with SMTP id RAA24221; Thu, 10 May 2001 17:14:23 GMT Received: from fmsmsx27.FM.INTEL.COM ([132.233.48.27]) by 132.233.48.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 10 May 2001 17:14:22 0000 (GMT) Received: by fmsmsx27.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 10 May 2001 10:14:20 -0700 Message-ID: <9287DC1579B0D411AA2F009027F44C3F042DFAAE@FMSMSX41> From: "Chan, Sun C" To: "'Stuart Hastings'" Cc: "'Robert Kennedy'" , shinmingliu@yahoo.com, pro64-support@oss.sgi.com Subject: RE: unoptimized dead store Date: Thu, 10 May 2001 10:14:18 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-pro64-support@oss.sgi.com Precedence: bulk > -----Original Message----- > From: Stuart Hastings [mailto:stuart@apple.com] > Sent: Thursday, May 10, 2001 9:32 AM > To: Chan, Sun C > Cc: Stuart Hastings; 'Robert Kennedy'; shinmingliu@yahoo.com; > pro64-support@oss.sgi.com > Subject: Re: unoptimized dead store > > > > On Wednesday, May 9, 2001, at 04:05 PM, Chan, Sun C wrote: > > > The other possibility is that since "a" is global, it could > be modified > > by a shared library. If you mark "a" as static, the > statement should go > > away. If not, it is back to your conjecture. > > BTW, thx for pointing out the obvious. > > Sun > > O.K., if 'a' is declared static, then it is immune from > tampering by a > shared library. However, I was hoping that IPA would be able to tell > that neither glarp() nor any of its callees reference > variable 'a'. If a > shared library was going to reference 'a', then glarp() or one of its > callees would be invoking an external function somewhere; they don't, > and IPA should know that. You're right, I looked at the test case more carefully and I retract my claim that "a" needs to be static. Even with shared library, "a" can be derived to be dead. This is what needs to happen: mod/ref info from call site glarp should return "a" not ref'd. Alias (mu/chi) building in Wopt should not have "a" on the list. Now 2 can be copy propagated into expression a+b and become 3+b. Both a=2 and a++ is now dead. What is not implemented in Wopt is Mu/Chi building not incorporating mod/ref info from IPA. This is a long standing item on the todo list. Any takers? Incidentally, this topic is also covered in a paper in the up coming PLDI. Sun From owner-pro64-support@oss.sgi.com Thu May 10 15:59:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4AMxv618539 for pro64-support-outgoing; Thu, 10 May 2001 15:59:57 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4AMxrF18533 for ; Thu, 10 May 2001 15:59:53 -0700 Received: from rohi.engr.sgi.com (rohi.engr.sgi.com [130.62.180.74]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id QAA07117 for ; Thu, 10 May 2001 16:10:44 -0700 (PDT) mail_from (mpm@rohi.engr.sgi.com) Received: (from mpm@localhost) by rohi.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id PAA60189; Thu, 10 May 2001 15:55:39 -0700 (PDT) Date: Thu, 10 May 2001 15:55:39 -0700 (PDT) From: mpm@rohi.engr.sgi.com (Michael Murphy) Message-Id: <200105102255.PAA60189@rohi.engr.sgi.com> To: pro64-support@oss.sgi.com, Clemens Helf Subject: Re: math library performance issue Sender: owner-pro64-support@oss.sgi.com Precedence: bulk From: Clemens Helf The function 'double pow (double x, double y)' (libmsgi.a) seems to have a severe performance problem. Substituting the call by 'exp(log(x)*y)' cuts down execution time by about one third. I checked with our math expert, and his response was: > Calling exp(log(x)*y) in place of pow(x, y) drops too many bits > to be useful. If that's what the user wants, he should code it > that way. Annother question is related to vector math: Will the compiler substitute a call to e.g. 'exp(x)' by the corresponding vector math function after loop optimization ? Again there are some precision issues: > One other problem in automatically generating calls to > the vector math intrinsics is that they are not as > accurate as the standard library. Moreover, the vector > log function doesn't support denormal arguments. -- Mike Murphy -- mpm@sgi.com -- quote of the day: -- "In marriage, being the right person is as important as -- finding the right person." (Wilbert Gough) From owner-pro64-support@oss.sgi.com Thu May 10 17:57:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4B0viD21226 for pro64-support-outgoing; Thu, 10 May 2001 17:57:44 -0700 Received: from mail-in.hq.tensilica.com (hq.tensilica.com [38.170.141.29]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4B0vhF21223 for ; Thu, 10 May 2001 17:57:43 -0700 Received: from tensilica.com (IDENT:jonhsu@leo-home.hq.tensilica.com [192.168.10.103]) by mail-in.hq.tensilica.com (8.9.3/8.9.3) with ESMTP id RAA27161 for ; Thu, 10 May 2001 17:57:42 -0700 Message-ID: <3AFB3904.F7884636@tensilica.com> Date: Thu, 10 May 2001 17:57:40 -0700 From: Jon Hsu X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: pro64-support@oss.sgi.com Subject: misaligned load/stores Content-Type: multipart/mixed; boundary="------------8484542A41B5AAFDBD6A570C" Sender: owner-pro64-support@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------8484542A41B5AAFDBD6A570C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit There seem to be situations where the Pro64 compiler generates misaligned loads and stores when it doesn't need to. I've attached a test case that demonstrates the problem. If you compile the test case with "sgicc -S -O2 ll_rw_blk.i" and look at the assembly for the function blk_queue_pluggable(), you'll see that the compiler uses 1-byte stores instead of an 8-byte store. I believe the problem is that the front end see an incomplete structure declaration, followed by a reference to a pointer to that structure, so that it creates a pointer type to a structure of alignment 1. Then when it sees the actual definition of the structure, it doesn't update the pointer type. --------------8484542A41B5AAFDBD6A570C Content-Type: text/plain; charset=us-ascii; name="ll_rw_blk.i" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ll_rw_blk.i" struct request_queue; typedef struct request_queue request_queue_t; typedef struct elevator_s elevator_t; struct elevator_s { int read_latency; int write_latency; request_queue_t *dequeue_fn; }; static inline int elevator_request_latency(elevator_t * elevator, int rw) { int latency; latency = elevator->read_latency; if (rw != 0 ) latency = elevator->write_latency; return latency; } struct request_queue { void * plug_device_fn; }; struct blk_dev_struct { request_queue_t request_queue; }; struct blk_dev_struct blk_dev[255 ]; void blk_queue_pluggable (request_queue_t * q, void *plug) { q->plug_device_fn = plug; } --------------8484542A41B5AAFDBD6A570C-- From owner-pro64-support@oss.sgi.com Fri May 11 08:33:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4BFXfo08761 for pro64-support-outgoing; Fri, 11 May 2001 08:33:41 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4BFXGF08755 for ; Fri, 11 May 2001 08:33:16 -0700 Received: from gaea.engr.sgi.com ([130.62.180.97]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id IAA03081 for ; Fri, 11 May 2001 08:32:45 -0700 (PDT) mail_from (murthy@gaea.engr.sgi.com) Received: (from murthy@localhost) by gaea.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id IAA70160; Fri, 11 May 2001 08:26:52 -0700 (PDT) Date: Fri, 11 May 2001 08:26:52 -0700 (PDT) From: murthy@gaea.engr.sgi.com (Chandrasekhar Murthy) Message-Id: <200105111526.IAA70160@gaea.engr.sgi.com> To: pro64-support@oss.sgi.com, Jon Hsu Subject: Re: misaligned load/stores Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Thanks for catching this. I will enter it into our bug database. Murthy From owner-pro64-support@oss.sgi.com Fri May 11 12:33:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4BJX4M22597 for pro64-support-outgoing; Fri, 11 May 2001 12:33:04 -0700 Received: from mail-in.hq.tensilica.com (hq.tensilica.com [38.170.141.29]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4BJX2F22584 for ; Fri, 11 May 2001 12:33:02 -0700 Received: from tensilica.com (IDENT:jonhsu@leo-home.hq.tensilica.com [192.168.10.103]) by mail-in.hq.tensilica.com (8.9.3/8.9.3) with ESMTP id MAA25643 for ; Fri, 11 May 2001 12:33:02 -0700 Message-ID: <3AFC3E6D.31376E93@tensilica.com> Date: Fri, 11 May 2001 12:33:01 -0700 From: Jon Hsu X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: pro64-support@oss.sgi.com Subject: segmentation fault Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pro64-support@oss.sgi.com Precedence: bulk I believe I've found a bug in the implementation of RELATED_SEGMENTED_ARRAY. The following code snippets are taken from cmplr_segmented_array.h. First, in Allocate(), a memory block of new_size elements is allocated. new_size is equal to either block_size or next_block_size. Next, in Update_Map, pairs are pushed onto the map vector. The first entry in the pair is a pointer and the second is a flag that indicates whether or not the pointer can be freed. Notice that if the block is larger than block_size, it is broken up into multiple pairs. Finally, in ~RELATED_SEGMENTED_ARRAY, every pointer in every pair is freed if the flag indicates that it is ok. Now, the problem comes when next_block_size is greater than block_size. For example, if next_block_size=256 and block_size=128, then new_size=256 and Update_Map() is called with a memory block of 256 elements. It creates two pairs from this block, one for each half of the memory block, and sets the own_memory flag to TRUE for both pairs. Finally, when the destructor is called, it tries to free both halves of the block separately, which causes a segmentation fault. Unfortunately, I cannot supply an example that demonstrates this problem, although I believe a simple call to Reserve(2*block_size) would do the trick. My suggestion is to change Update_Map() as indicated below to only free the first entry when a block is larger than block_size. However, you may have a better idea, or may know of other data structures which might have similar problems. template void RELATED_SEGMENTED_ARRAY::Allocate () { Is_True (size == max_size, ("Invalid internal state in segmented array")); UINT new_size; if (next_block_size == 0) new_size = block_size; else { new_size = Round_up (next_block_size); next_block_size = 0; } block = (T *) MEM_POOL_Alloc (pool, new_size * sizeof(T)); max_size += new_size; block_base = size; Update_Map (block, new_size, TRUE); } // RELATED_SEGMENTED_ARRAY::Allocate template inline void RELATED_SEGMENTED_ARRAY::Update_Map(T *marker, UINT new_size, BOOL own_memory) { do { map.push_back(std::pair(marker, own_memory)); new_size -= block_size; marker += block_size; own_memory = FALSE; // Only the first entry can be freed for a block that // is larger than block_size. } while (new_size); } // RELATED_SEGMENTED_ARRAY::Update_Map ~RELATED_SEGMENTED_ARRAY() { // Free memory from blocks. Map memory gets freed when the map // vector is destructed. for (std::vector, mempool_allocator >::iterator entry = map.begin(); entry != map.end(); ++entry) { // entry->second <==> this map entry owns the block's memory. if (entry->second) { MEM_POOL_FREE(pool, entry->first); } } From owner-pro64-support@oss.sgi.com Fri May 11 22:17:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4C5HLi30675 for pro64-support-outgoing; Fri, 11 May 2001 22:17:21 -0700 Received: from scapa.cs.ualberta.ca (root@scapa.cs.ualberta.ca [129.128.4.44]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4C5HGF30671 for ; Fri, 11 May 2001 22:17:20 -0700 Received: (from localhost user: 'pengzhao' uid#483 fake: STDIN (pengzhao@peers)) by scapa.cs.ualberta.ca id ; Fri, 11 May 2001 23:17:05 -0600 Date: Fri, 11 May 2001 23:16:54 -0600 (MDT) From: Peng Zhao To: sgi Subject: confusion on parameters of __profile_call_entry Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-2138965737-1129359374-989644614=:32733" Sender: owner-pro64-support@oss.sgi.com Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---2138965737-1129359374-989644614=:32733 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, I dumped the whirl tree of the instrumented program. I got confused on the number of the parameters of __profile_call_entry and __profile_call_exit. The prototype of __profile_call_exit is void __profile_call_entry(void *pu_handle, int call_id); but in the dumped whirl tree, it seems to me that it get three parameters: BLOCK U8U8LDID 264 <1,5,.preg_U8> T<9,.predef_U8,8> # pu_instrument_handle U8PARM 2 T<9,.predef_U8,8> # by_value I4INTCONST 0 (0x0) I4PARM 2 T<4,.predef_I4,4> # by_value U8LDA 0 <1,26,(7_bytes)_"printf\000"> T<34,anon_ptr.,8> U8PARM 2 T<9,.predef_U8,8> # by_value VCALL 126 <1,27,__profile_call_entry> # flags 0x7e LOC 1 10 { LOC 1 11 printf("hi, i > 100\n"); U8LDA 0 <1,22,(13_bytes)_"hi,_i_>_100\n\000"> T<32,anon_ptr.,8> U8PARM 2 T<28,anon_ptr.,8> # by_value VCALL 126 <1,21,printf> # flags 0x7e U8U8LDID 264 <1,5,.preg_U8> T<9,.predef_U8,8> # pu_instrument_handle U8PARM 2 T<9,.predef_U8,8> # by_value I4INTCONST 0 (0x0) I4PARM 2 T<4,.predef_I4,4> # by_value U8LDA 0 <1,26,(7_bytes)_"printf\000"> T<34,anon_ptr.,8> U8PARM 2 T<9,.predef_U8,8> # by_value VCALL 126 <1,28,__profile_call_exit> # flags 0x7e END_BLOCK What happens? It seems to me that Instrument_Call calls the wrong Gen_Call (or Gen_Call_Shell). The source program is very simple and enclosed. Thanks for your help. Peng ---2138965737-1129359374-989644614=:32733 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="test.c" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="test.c" I2luY2x1ZGUgPHN0ZGlvLmg+DQoNCm1haW4oKQ0Kew0KCWludCBpOw0KCQ0K CWk9MjAwOw0KDQoJaWYoaT4xMDApDQoJew0KCQlwcmludGYoImhpLCBpID4g MTAwXG4iKTsJDQoJfWVsc2UNCgl7DQoJCXByaW50ZigiaGksIGkgPCAxMDBc biIpOwkNCgl9DQoNCn0NCg== ---2138965737-1129359374-989644614=:32733-- From owner-pro64-support@oss.sgi.com Sat May 12 15:22:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4CMM6r11790 for pro64-support-outgoing; Sat, 12 May 2001 15:22:06 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4CMM1F11783 for ; Sat, 12 May 2001 15:22:02 -0700 Received: from dsl-proof.corp.sgi.com ([192.102.142.250]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id PAA03116 for ; Sat, 12 May 2001 15:21:32 -0700 (PDT) mail_from (dlstephe@sgi.com) Received: from sgi.com (localhost [127.0.0.1]) by dsl-proof.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id PAA05378; Sat, 12 May 2001 15:17:45 -0700 (PDT) Message-ID: <3AFDB688.3346F345@sgi.com> Date: Sat, 12 May 2001 15:17:44 -0700 From: David Stephenson Organization: SGI -- Compilers X-Mailer: Mozilla 4.7C-SGI [en] (X11; I; IRIX 6.5 IP32) X-Accept-Language: en MIME-Version: 1.0 To: Peng Zhao CC: sgi Subject: Re: confusion on parameters of __profile_call_entry References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Peng Zhao wrote: > I dumped the whirl tree of the instrumented program. I got > confused on the number of the parameters of __profile_call_entry > and __profile_call_exit. > > The prototype of __profile_call_exit is > void __profile_call_entry(void *pu_handle, int call_id); > > but in the dumped whirl tree, it seems to me that it get three parameters: ... > U8U8LDID 264 <1,5,.preg_U8> T<9,.predef_U8,8> # pu_instrument_handle > U8PARM 2 T<9,.predef_U8,8> # by_value > I4INTCONST 0 (0x0) > I4PARM 2 T<4,.predef_I4,4> # by_value > U8LDA 0 <1,26,(7_bytes)_"printf\000"> T<34,anon_ptr.,8> > U8PARM 2 T<9,.predef_U8,8> # by_value > VCALL 126 <1,27,__profile_call_entry> # flags 0x7e ... > What happens? It seems to me that Instrument_Call calls the wrong > Gen_Call (or Gen_Call_Shell). You are right. I'm a little surprised that this isn't causing problems, but perhaps the third parameter is being harmlessly ignored. My guess is that it's obsolete. I'll try updating Instrument_Call in be/com/wn_instrument.cxx to avoid producing the third parameter. Thanks for pointing that out. I like deleting code. - David -- David Stephenson http://reality.sgi.com/dlstephe_engr/ From owner-pro64-support@oss.sgi.com Sat May 12 15:44:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4CMi8B12359 for pro64-support-outgoing; Sat, 12 May 2001 15:44:08 -0700 Received: from zero.aec.at (qmailr@zero.aec.at [195.3.98.22]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4CMi7F12355 for ; Sat, 12 May 2001 15:44:07 -0700 Received: (qmail 10620 invoked by uid 99); 12 May 2001 22:43:49 -0000 Received: from unknown (HELO fred.muc.de) (unknown) by unknown with SMTP; 12 May 2001 22:43:49 -0000 Received: by fred.muc.de (Postfix, from userid 500) id 10B1EE3911; Sun, 13 May 2001 00:53:40 +0200 (CEST) Date: Sun, 13 May 2001 00:53:40 +0200 From: Andi Kleen To: pro64-support@oss.sgi.com Subject: Remove simplification Message-ID: <20010513005340.A6369@fred.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i Sender: owner-pro64-support@oss.sgi.com Precedence: bulk This patch removes an incorrect simplification: !!x is not x in C. -Andi --- osprey1.0/common/com/wn_simp_code.h-o Mon Mar 12 23:28:23 2001 +++ osprey1.0/common/com/wn_simp_code.h Sun May 13 00:50:36 2001 @@ -1118,7 +1118,6 @@ /*------------------------------------------------ Simplifications for ~ and !: - ! ! j j ~ ~ j j ! inverse comp, IEEE_comparisons false for floating point ~(a | b) a nor b @@ -1133,7 +1132,7 @@ simpnode r = NULL; OPCODE inverse_relop; - if (opc == SIMPNODE_opcode(k0)) { + if (opc != OPR_LNOT && opc == SIMPNODE_opcode(k0)) { SHOW_RULE("~ ~ j -> j"); r = SIMPNODE_kid0(k0); SIMP_DELETE(k0); -- Life would be so much easier if we could just look at the source code. From owner-pro64-support@oss.sgi.com Mon May 14 06:38:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4EDcAk12592 for pro64-support-outgoing; Mon, 14 May 2001 06:38:10 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4EDc9F12589 for ; Mon, 14 May 2001 06:38:09 -0700 Received: from sgihud.hudson.sgi.com (sgihud.hudson.sgi.com [169.238.41.4]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id GAA04355 for ; Mon, 14 May 2001 06:49:04 -0700 (PDT) mail_from (lesniak@sgihud.hudson.sgi.com) Received: (from lesniak@localhost) by sgihud.hudson.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id JAA11420; Mon, 14 May 2001 09:36:51 -0400 (EDT) Date: Mon, 14 May 2001 09:36:51 -0400 (EDT) From: lesniak@sgihud.hudson.sgi.com (Ken Lesniak) Message-Id: <200105141336.JAA11420@sgihud.hudson.sgi.com> To: pro64-support@oss.sgi.com, Andi Kleen Subject: Re: Remove simplification Reply-To: lesniak@sgihud.hudson.sgi.com Sender: owner-pro64-support@oss.sgi.com Precedence: bulk >From: Andi Kleen > >This patch removes an incorrect simplification: !!x is not x in C. It is valid if you know x is 0 or 1. This will be the case if x is a relational operator or of boolean type (MTYPE_B). If the simplification doesn't check for this, then I agree it's wrong. We'll have to take a closer look. Do you have a test case or some bug which this caused trouble with? Thank, Ken >-Andi > >--- osprey1.0/common/com/wn_simp_code.h-o Mon Mar 12 23:28:23 2001 >+++ osprey1.0/common/com/wn_simp_code.h Sun May 13 00:50:36 2001 >@@ -1118,7 +1118,6 @@ > /*------------------------------------------------ > Simplifications for ~ and !: > >- ! ! j j > ~ ~ j j > ! inverse comp, IEEE_comparisons false for floating point > ~(a | b) a nor b >@@ -1133,7 +1132,7 @@ > simpnode r = NULL; > OPCODE inverse_relop; > >- if (opc == SIMPNODE_opcode(k0)) { >+ if (opc != OPR_LNOT && opc == SIMPNODE_opcode(k0)) { > SHOW_RULE("~ ~ j -> j"); > r = SIMPNODE_kid0(k0); > SIMP_DELETE(k0); > > > > >-- >Life would be so much easier if we could just look at the source code. > From owner-pro64-support@oss.sgi.com Mon May 14 07:56:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4EEuF314222 for pro64-support-outgoing; Mon, 14 May 2001 07:56:15 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4EEtiF14214 for ; Mon, 14 May 2001 07:55:45 -0700 Received: from gaea.engr.sgi.com ([130.62.180.97]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id HAA03081 for ; Mon, 14 May 2001 07:53:51 -0700 (PDT) mail_from (murthy@gaea.engr.sgi.com) Received: (from murthy@localhost) by gaea.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id HAA72582; Mon, 14 May 2001 07:46:55 -0700 (PDT) Date: Mon, 14 May 2001 07:46:55 -0700 (PDT) From: murthy@gaea.engr.sgi.com (Chandrasekhar Murthy) Message-Id: <200105141446.HAA72582@gaea.engr.sgi.com> To: pro64-support@oss.sgi.com, Andi Kleen Subject: Re: Remove simplification Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Most probably I think this is a frontend problem because it is not normalizing the condition. The frontend should represent the condition x as x != 0. This is required as per WHIRL definition. Murthy From owner-pro64-support@oss.sgi.com Mon May 14 08:30:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4EFUmZ15110 for pro64-support-outgoing; Mon, 14 May 2001 08:30:48 -0700 Received: from mail-in.hq.tensilica.com (hq.tensilica.com [38.170.141.29]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4EFUmF15107 for ; Mon, 14 May 2001 08:30:48 -0700 Received: from corvus.hq.tensilica.com (IDENT:robert@corvus.hq.tensilica.com [192.168.15.29]) by mail-in.hq.tensilica.com (8.9.3/8.9.3) with ESMTP id IAA10534; Mon, 14 May 2001 08:30:47 -0700 Date: Mon, 14 May 2001 08:30:47 -0700 Message-Id: <200105141530.IAA10534@mail-in.hq.tensilica.com> From: Robert Kennedy To: jonhsu@tensilica.com CC: pro64-support@oss.sgi.com In-reply-to: <3AFC3E6D.31376E93@tensilica.com> (message from Jon Hsu on Fri, 11 May 2001 12:33:01 -0700) Subject: Re: segmentation fault References: <3AFC3E6D.31376E93@tensilica.com> Sender: owner-pro64-support@oss.sgi.com Precedence: bulk > I believe I've found a bug in the implementation of > RELATED_SEGMENTED_ARRAY... I think I originally implemented that template. I'll take a look at the problem. -- Robert From owner-pro64-support@oss.sgi.com Mon May 14 08:31:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4EFV7N15169 for pro64-support-outgoing; Mon, 14 May 2001 08:31:07 -0700 Received: from gate.init.com ([38.138.181.132]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4EFV6F15164 for ; Mon, 14 May 2001 08:31:07 -0700 Received: from denali.abinitio.com (localmail.init.com [10.50.30.91]) by gate.init.com (8.9.3/8.9.3/ab-gate-1.1) with ESMTP id LAA09324; Mon, 14 May 2001 11:30:32 -0400 Received: from neo.init.com (neo.init.com [10.50.20.69]) by denali.abinitio.com (8.9.3/8.9.3/ab-hub-1.2) with ESMTP id LAA26693; Mon, 14 May 2001 11:30:14 -0400 (EDT) Received: (from rshapiro@localhost) by neo.init.com (8.9.3/8.8.8/ab-cli-1.1) id LAA30442; Mon, 14 May 2001 11:30:14 -0400 Date: Mon, 14 May 2001 11:30:14 -0400 Message-Id: <200105141530.LAA30442@neo.init.com> X-Authentication-Warning: neo.init.com: rshapiro set sender to rshapiro@neo.init.com using -f From: Richard Shapiro To: ak@muc.de CC: pro64-support@oss.sgi.com In-reply-to: <20010513005340.A6369@fred.local> (message from Andi Kleen on Sun, 13 May 2001 00:53:40 +0200) Subject: Re: Remove simplification References: <20010513005340.A6369@fred.local> Sender: owner-pro64-support@oss.sgi.com Precedence: bulk X-Authentication-Warning: oss.sgi.com: mail owned process doing -bs Date: Sun, 13 May 2001 00:53:40 +0200 From: Andi Kleen Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Content-Type: text/plain; charset=us-ascii Content-Length: 816 This patch removes an incorrect simplification: !!x is not x in C. -Andi !!x is not x in C, but it is in WHIRL. From owner-pro64-support@oss.sgi.com Mon May 14 09:34:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4EGYpi16678 for pro64-support-outgoing; Mon, 14 May 2001 09:34:51 -0700 Received: from mail-in.hq.tensilica.com (hq.tensilica.com [38.170.141.29]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4EGYoF16675 for ; Mon, 14 May 2001 09:34:50 -0700 Received: from corvus.hq.tensilica.com (IDENT:robert@corvus.hq.tensilica.com [192.168.15.29]) by mail-in.hq.tensilica.com (8.9.3/8.9.3) with ESMTP id JAA27607; Mon, 14 May 2001 09:33:37 -0700 Date: Mon, 14 May 2001 09:33:35 -0700 Message-Id: <200105141633.JAA27607@mail-in.hq.tensilica.com> From: Robert Kennedy To: jonhsu@tensilica.com CC: pro64-support@oss.sgi.com In-reply-to: <3AFC3E6D.31376E93@tensilica.com> (message from Jon Hsu on Fri, 11 May 2001 12:33:01 -0700) Subject: Re: segmentation fault References: <3AFC3E6D.31376E93@tensilica.com> Sender: owner-pro64-support@oss.sgi.com Precedence: bulk > I believe I've found a bug in the implementation of > RELATED_SEGMENTED_ARRAY. Now that I've read your message more carefully, I believe the feature under discussion is something that got added after I worked on the RELATED_SEGMENTED_ARRAY template. So I am not much of an expert in this area, but I think your suggested fix is a good one. Conceptually, the decisions about who should free memory (in other words, whether the template class's destructor should free the blocks) should be made and recorded at the point where the template class either receives a block from outside, or allocates a new block itself. The fundamental reason for the problem you observed is that someone tried to put this decision in two separate places (allocations and intake of outside blocks are done in one place, while the flags recording who owns the memory are recorded in another). Doing that is almost always a bad idea because it's error prone, fragile, and hard to understand. Your suggestion is the easy way out; doing it right (now that it has been done wrong) seems like it would take more work... That's why I think it would be reasonable to implement your idea. -- Robert From owner-pro64-support@oss.sgi.com Mon May 14 12:06:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4EJ6mj19845 for pro64-support-outgoing; Mon, 14 May 2001 12:06:48 -0700 Received: from postman.eglin.af.mil ([129.61.132.2]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4EJ6lF19842 for ; Mon, 14 May 2001 12:06:47 -0700 Received: from filter1.eglin.af.mil (filter1.eglin.af.mil [129.61.2.39]) by postman.eglin.af.mil (8.12.0.Beta7/8.11.3) with SMTP id f4EJ6PBA022166 for ; Mon, 14 May 2001 14:06:25 -0500 (CDT) Received: from filter1.eglin.af.mil ([129.61.2.39]) by filter1.eglin.af.mil (NAVIEG 2.1 bld 63) with SMTP id M2001051414062318066 for ; Mon, 14 May 2001 14:06:23 -0500 Received: FROM hub2.eglin.af.mil BY filter1.eglin.af.mil ; Mon May 14 14:06:22 2001 -0500 Received: by hub2.eglin.af.mil with Internet Mail Service (5.5.2653.19) id ; Mon, 14 May 2001 14:06:23 -0500 Message-ID: <06E81F7304CED4119035009027E52EA3687DE3@eg-002-012.eglin.af.mil> From: Coffman Jarrett J Contr 96 CG/SCWDE To: "'pro64-support@oss.sgi.com'" Subject: Version 0.12 Date: Mon, 14 May 2001 14:06:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0DCA8.F3A90250" Sender: owner-pro64-support@oss.sgi.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0DCA8.F3A90250 Content-Type: text/plain; charset="iso-8859-1" How do I get a copy of Version 0.12 to use with NUE? ------_=_NextPart_001_01C0DCA8.F3A90250 Content-Type: text/html; charset="iso-8859-1" Version 0.12

How do I get a copy of Version 0.12 to use with NUE?

------_=_NextPart_001_01C0DCA8.F3A90250-- From owner-pro64-support@oss.sgi.com Mon May 14 12:49:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4EJnlW21212 for pro64-support-outgoing; Mon, 14 May 2001 12:49:47 -0700 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4EJnkF21208 for ; Mon, 14 May 2001 12:49:46 -0700 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 95F241E0BC; Mon, 14 May 2001 21:49:45 +0200 (MEST) Date: Mon, 14 May 2001 21:49:07 +0200 From: Andi Kleen To: Ken Lesniak Cc: pro64-support@oss.sgi.com, Andi Kleen Subject: Re: Remove simplification Message-ID: <20010514214907.A2666@gruyere.muc.suse.de> References: <200105141336.JAA11420@sgihud.hudson.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200105141336.JAA11420@sgihud.hudson.sgi.com>; from lesniak@sgihud.hudson.sgi.com on Mon, May 14, 2001 at 09:36:51AM -0400 Sender: owner-pro64-support@oss.sgi.com Precedence: bulk On Mon, May 14, 2001 at 09:36:51AM -0400, Ken Lesniak wrote: > Do you have a test case or some bug which this caused trouble with? main() { printf("%d\n",!!5); } If whirl !! is not like C !! it is probably a frontend bug though. -Andi From owner-pro64-support@oss.sgi.com Mon May 14 13:57:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4EKvBN22806 for pro64-support-outgoing; Mon, 14 May 2001 13:57:11 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4EKuuF22800 for ; Mon, 14 May 2001 13:56:56 -0700 Received: from gaea.engr.sgi.com ([130.62.180.97]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id NAA06060 for ; Mon, 14 May 2001 13:56:16 -0700 (PDT) mail_from (murthy@gaea.engr.sgi.com) Received: (from murthy@localhost) by gaea.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id NAA75428; Mon, 14 May 2001 13:48:03 -0700 (PDT) Date: Mon, 14 May 2001 13:48:03 -0700 (PDT) From: murthy@gaea.engr.sgi.com (Chandrasekhar Murthy) Message-Id: <200105142048.NAA75428@gaea.engr.sgi.com> To: Ken Lesniak , Andi Kleen Subject: Re: Remove simplification Cc: Andi Kleen , pro64-support@oss.sgi.com References: <200105141336.JAA11420@sgihud.hudson.sgi.com> Sender: owner-pro64-support@oss.sgi.com Precedence: bulk > main() > { > printf("%d\n",!!5); > } Should print 1 and when it is compiled with sgicc, it does print 1. Are you getting a different value. Murthy From owner-pro64-support@oss.sgi.com Thu May 17 07:42:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4HEgEu14637 for pro64-support-outgoing; Thu, 17 May 2001 07:42:14 -0700 Received: from mail.eecis.udel.edu (louie.udel.edu [128.175.2.33]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4HEgDF14634 for ; Thu, 17 May 2001 07:42:13 -0700 Received: from louie.udel.edu by mail.eecis.udel.edu id aa12214; 17 May 2001 10:41 EDT Date: Thu, 17 May 2001 10:41:41 -0400 (EDT) From: Haiping Wu To: pro64-support@oss.sgi.com MMDF-Warning: Parse error in original version of preceding line at mail.eecis.udel.edu Subject: How to turn off the register stack? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pro64-support@oss.sgi.com Precedence: bulk I try to use the memory stack instead of register stack(r32~r127). I try to throw all the register stack away completely. Is there any way to do this? Thanks. --Haiping Wu From owner-pro64-support@oss.sgi.com Thu May 17 10:31:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4HHVdA18908 for pro64-support-outgoing; Thu, 17 May 2001 10:31:39 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4HHVWF18902 for ; Thu, 17 May 2001 10:31:32 -0700 Received: from rohi.engr.sgi.com ([130.62.180.74]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id KAA08324 for ; Thu, 17 May 2001 10:31:29 -0700 (PDT) mail_from (mpm@rohi.engr.sgi.com) Received: (from mpm@localhost) by rohi.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id KAA79319; Thu, 17 May 2001 10:27:29 -0700 (PDT) Date: Thu, 17 May 2001 10:27:29 -0700 (PDT) From: mpm@rohi.engr.sgi.com (Michael Murphy) Message-Id: <200105171727.KAA79319@rohi.engr.sgi.com> To: pro64-support@oss.sgi.com, Haiping Wu Subject: Re: How to turn off the register stack? Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Can't be done. The register stack is necessary for basic things like parameter passing. Of course you can always retarget the source to a different machine, but ia64 needs the register stack. -- Mike Murphy -- mpm@sgi.com -- quote of the day: -- "Follow the three Rs: -- Respect for self -- Respect for others and -- Responsibility for all your actions." (Dalai Lama) From owner-pro64-support@oss.sgi.com Thu May 17 12:47:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4HJlLY22596 for pro64-support-outgoing; Thu, 17 May 2001 12:47:21 -0700 Received: from scapa.cs.ualberta.ca (scapa.cs.ualberta.ca [129.128.4.44]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4HJl4F22592 for ; Thu, 17 May 2001 12:47:15 -0700 Received: (from localhost user: 'pengzhao' uid#483 fake: STDIN (pengzhao@peers)) by scapa.cs.ualberta.ca id ; Thu, 17 May 2001 13:46:30 -0600 Date: Thu, 17 May 2001 13:46:30 -0600 (MDT) From: Peng Zhao To: sgi Subject: usage of daVinci Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Hi, Can somebody tell me some exciting usage of daVinci? I found that it only demonstrates the whirl tree or sth like that with too simple information. Is there any other "advanced" usage of this tool? -- Regards Peng Peng Zhao pengzhao@cs.ualberta.ca http://www.cs.ualberta.ca/~pengzhao TEL (Lab): (780)492-3725 Lab: CSC251 From owner-pro64-support@oss.sgi.com Thu May 17 18:56:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4I1uvQ02581 for pro64-support-outgoing; Thu, 17 May 2001 18:56:57 -0700 Received: from mail.ict.ac.cn ([159.226.39.4]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4I1utF02578 for ; Thu, 17 May 2001 18:56:55 -0700 Received: (qmail 29045 invoked from network); 18 May 2001 01:51:30 -0000 Received: from unknown (HELO zsk) (@159.226.40.246) by 159.226.39.4 with SMTP; 18 May 2001 01:51:30 -0000 Message-ID: <000c01c0df3e$2f973920$280379c8@zsk> From: "Shukang ZHOU" To: "Peng Zhao" , "sgi" References: Subject: Re: usage of daVinci Date: Fri, 18 May 2001 09:59:21 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-pro64-support@oss.sgi.com Precedence: bulk It can display the Control Flow Graph of each program unit with daVinci, using the option of -Wb,-tt:57:0x100. Shukang ZHOU Advanced Compiler Technology Group Institute of Computing Technology, Chinese Academy of Sciences E-mail: zhshk@ict.ac.cn ----- Original Message ----- From: "Peng Zhao" To: "sgi" Sent: Friday, May 18, 2001 3:46 AM Subject: usage of daVinci > > Hi, > > Can somebody tell me some exciting usage of daVinci? I found that > it only demonstrates the whirl tree or sth like that with too simple > information. Is there any other "advanced" usage of this tool? > > -- > Regards > > Peng > Peng Zhao pengzhao@cs.ualberta.ca > http://www.cs.ualberta.ca/~pengzhao > TEL (Lab): (780)492-3725 Lab: CSC251 > > > From owner-pro64-support@oss.sgi.com Thu May 17 20:04:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4I342i04126 for pro64-support-outgoing; Thu, 17 May 2001 20:04:02 -0700 Received: from mail.ict.ac.cn ([159.226.39.4]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4I340F04123 for ; Thu, 17 May 2001 20:04:01 -0700 Received: (qmail 1857 invoked from network); 18 May 2001 02:58:36 -0000 Received: from unknown (HELO zsk) (@159.226.40.246) by 159.226.39.4 with SMTP; 18 May 2001 02:58:36 -0000 Message-ID: <009301c0df47$8f1194a0$280379c8@zsk> From: "Shukang ZHOU" To: "sgi" References: Subject: Re: usage of daVinci Date: Fri, 18 May 2001 11:06:36 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Sorry for my typo. the option is -Wb,-tt57:0x100 and I am using Pro64. Shukang ZHOU Advanced Compiler Technology Group Institute of Computing Technology, Chinese Academy of Sciences E-mail: zhshk@ict.ac.cn ----- Original Message ----- From: "Peng Zhao" To: "Shukang ZHOU" Sent: Friday, May 18, 2001 10:52 AM Subject: Re: usage of daVinci > > thanks. r u using pro64? > > it complains that the 0x100 is out of range. > > > On Fri, 18 May 2001, Shukang ZHOU wrote: > > > It can display the Control Flow Graph of each program unit with daVinci, > > using the option of -Wb,-tt:57:0x100. > > > > Shukang ZHOU > > Advanced Compiler Technology Group > > Institute of Computing Technology, Chinese Academy of Sciences > > E-mail: zhshk@ict.ac.cn > > > > ----- Original Message ----- > > From: "Peng Zhao" > > To: "sgi" > > Sent: Friday, May 18, 2001 3:46 AM > > Subject: usage of daVinci > > > > > > > > > > Hi, > > > > > > Can somebody tell me some exciting usage of daVinci? I found that > > > it only demonstrates the whirl tree or sth like that with too simple > > > information. Is there any other "advanced" usage of this tool? > > > > > > -- > > > Regards > > > > > > Peng > > > Peng Zhao pengzhao@cs.ualberta.ca > > > http://www.cs.ualberta.ca/~pengzhao > > > TEL (Lab): (780)492-3725 Lab: CSC251 > > > > > > > > > > > > > -- > Regards > > Peng > Peng Zhao pengzhao@cs.ualberta.ca > http://www.cs.ualberta.ca/~pengzhao > TEL (Lab): (780)492-3725 Lab: CSC251 > > > > From owner-pro64-support@oss.sgi.com Mon May 21 03:39:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4LAd2X05216 for pro64-support-outgoing; Mon, 21 May 2001 03:39:02 -0700 Received: from ganymede.or.intel.com (jffdns01.or.intel.com [134.134.248.3]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4LAd1F05212 for ; Mon, 21 May 2001 03:39:02 -0700 Received: from SMTP (orsmsxvs02-1.jf.intel.com [192.168.65.201]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.39 2001/05/18 00:47:02 root Exp $) with SMTP id KAA13043 for ; Mon, 21 May 2001 10:38:44 GMT Received: from orsmsx28.jf.intel.com ([192.168.70.28]) by 192.168.70.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Mon, 21 May 2001 10:38:44 0000 (GMT) Received: by orsmsx28.jf.intel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 21 May 2001 03:38:42 -0700 Received: from fmsmsxfw01.fm.intel.com ([192.168.133.200]) by fmsmsx27.FM.INTEL.COM with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LGMF45XM; Mon, 21 May 2001 03:38:36 -0700 Received: by ldap.intel.com with Internet Mail Service (5.5.2650.21) id ; Mon, 21 May 2001 18:51:44 +0800 Message-ID: From: "Tuo, Tony" To: "'pro64-support@oss.sgi.com'" Subject: compiling error "integer constant out of range" when building pro 64 0.13 with gcc 2.95.2 Date: Mon, 21 May 2001 18:37:56 +0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-pro64-support@oss.sgi.com Precedence: bulk This error occurred when compiling be/cg/exp_loadstore.cxx. It's caused by the macro definition in cg/variants.h in line 254/255/256: line 254: #define V_pf_flags(v) ((UINT32)(((v) & V_PF_FLAGS) >>32)) Is there any problems in this definition? Tuo From owner-pro64-support@oss.sgi.com Mon May 21 06:58:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4LDww709965 for pro64-support-outgoing; Mon, 21 May 2001 06:58:58 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4LDwuF09962 for ; Mon, 21 May 2001 06:58:56 -0700 Received: from sgihud.hudson.sgi.com (sgihud.hudson.sgi.com [169.238.41.4]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id PAA398803 for ; Mon, 21 May 2001 15:58:53 +0200 (CEST) mail_from (lesniak@sgihud.hudson.sgi.com) Received: (from lesniak@localhost) by sgihud.hudson.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id JAA56534; Mon, 21 May 2001 09:57:36 -0400 (EDT) Date: Mon, 21 May 2001 09:57:36 -0400 (EDT) From: lesniak@sgihud.hudson.sgi.com (Ken Lesniak) Message-Id: <200105211357.JAA56534@sgihud.hudson.sgi.com> To: "'pro64-support@oss.sgi.com'" , "Tuo, Tony" Subject: Re: compiling error "integer constant out of range" when building pro 64 0.13 with gcc 2.95.2 Reply-To: lesniak@sgihud.hudson.sgi.com Sender: owner-pro64-support@oss.sgi.com Precedence: bulk >From: "Tuo, Tony" > >This error occurred when compiling be/cg/exp_loadstore.cxx. It's caused by the macro definition in cg/variants.h in line 254/255/256: >line 254: #define V_pf_flags(v) ((UINT32)(((v) & V_PF_FLAGS) >>32)) > >Is there any problems in this definition? > >Tuo Hi, Someone on the list recently pointed out our error in variants.h. The solution is to change the definition of V_PF_FLAGS so that it has a ULL suffix: #define V_PF_FLAGS 0xffffffff00000000ULL /* Prefetch flags */ Ken From owner-pro64-support@oss.sgi.com Mon May 21 07:06:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4LE6pY10264 for pro64-support-outgoing; Mon, 21 May 2001 07:06:51 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4LE6iF10261 for ; Mon, 21 May 2001 07:06:45 -0700 Received: from gaea.engr.sgi.com (gaea.engr.sgi.com [130.62.180.97]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id QAA397801 for ; Mon, 21 May 2001 16:06:42 +0200 (CEST) mail_from (murthy@gaea.engr.sgi.com) Received: (from murthy@localhost) by gaea.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id HAA06725; Mon, 21 May 2001 07:00:26 -0700 (PDT) Date: Mon, 21 May 2001 07:00:26 -0700 (PDT) From: murthy@gaea.engr.sgi.com (Chandrasekhar Murthy) Message-Id: <200105211400.HAA06725@gaea.engr.sgi.com> To: "'pro64-support@oss.sgi.com'" , "Tuo, Tony" Subject: Re: compiling error "integer constant out of range" when building pro 64 0.13 with gcc 2.95.2 Sender: owner-pro64-support@oss.sgi.com Precedence: bulk This was reported a few weeks back. I think Ken Lesniak fixed it. The definition of V_PF_FLAGS in variants.h should have the ULL suffix as indicated below #define V_PF_FLAGS 0xffffffff00000000ULL /* Prefetch flags */ Murthy From owner-pro64-support@oss.sgi.com Tue May 22 12:23:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4MJNHp14542 for pro64-support-outgoing; Tue, 22 May 2001 12:23:17 -0700 Received: from escelsa.com.br (smtp.escelsanet.com.br [200.242.30.218]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4MJMbF14455 for ; Tue, 22 May 2001 12:23:16 -0700 Received: from blackbird.conexo.com.br ([200.242.27.81]) by escelsa.com.br ; Tue, 22 May 2001 16:22:31 -0300 From: Sandro Camata To: pro64-support@oss.sgi.com Subject: How to modify the itanium target info Date: Tue, 22 May 2001 16:07:44 -0300 X-Mailer: KMail [version 1.0.29] Content-Type: text/plain MIME-Version: 1.0 Message-Id: <01052216243100.22692@blackbird.conexo.com.br> Content-Transfer-Encoding: 8bit Sender: owner-pro64-support@oss.sgi.com Precedence: bulk How can I modify the instruction latency and functional unit resource quantity? Is the file itanium_si.cxx the only file to change? How the "issue" resource quantity information is used in this file? I tried to change the issue resource from 6 to 15 (in file itanium_si.cxx) but when running the compiler I got an error "Error: Signal Segmentation fault in phase Software Pipelining". I'm making experiments to compare some architetures and I need to have a normalized number of functional units and instruction latency. Thanks Sandro Camata camata@computer.org UFES - Universidade Federal do Espírito Santo - Brasil From owner-pro64-support@oss.sgi.com Tue May 22 12:35:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4MJZc415048 for pro64-support-outgoing; Tue, 22 May 2001 12:35:38 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4MJZMF15042 for ; Tue, 22 May 2001 12:35:22 -0700 Received: from sgihud.hudson.sgi.com (sgihud.hudson.sgi.com [169.238.41.4]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA07284 for ; Tue, 22 May 2001 12:33:56 -0700 (PDT) mail_from (lesniak@sgihud.hudson.sgi.com) Received: (from lesniak@localhost) by sgihud.hudson.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id PAA56113; Tue, 22 May 2001 15:33:53 -0400 (EDT) Date: Tue, 22 May 2001 15:33:53 -0400 (EDT) From: lesniak@sgihud.hudson.sgi.com (Ken Lesniak) Message-Id: <200105221933.PAA56113@sgihud.hudson.sgi.com> To: pro64-support@oss.sgi.com, Sandro Camata Subject: Re: How to modify the itanium target info Reply-To: lesniak@sgihud.hudson.sgi.com Sender: owner-pro64-support@oss.sgi.com Precedence: bulk >From: Sandro Camata > >How can I modify the instruction latency and functional unit resource >quantity? Is the file itanium_si.cxx the only file to change? There may be some assumptions in other places, but itanium_si.cxx is intended to encapsulated the latency and function unit resources. >How the "issue" resource quantity information is used in this file? The effectively determines the maximum number of instructions that can be executed in a single cycle. >I tried to change the issue resource from 6 to 15 (in file >itanium_si.cxx) but when running the compiler I got an error >"Error: Signal Segmentation fault in phase Software Pipelining". I would guess SWP is making some kind of assumption about how many issue slots there are. >I'm making experiments to compare some architetures and I need to have >a normalized number of functional units and instruction latency. Interesting, but this will be challenging I bet! Ken From owner-pro64-support@oss.sgi.com Wed May 23 08:05:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4NF5Ue10368 for pro64-support-outgoing; Wed, 23 May 2001 08:05:30 -0700 Received: from roura.ac.upc.es (roura.ac.upc.es [147.83.33.10]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4NF5TF10365 for ; Wed, 23 May 2001 08:05:29 -0700 Received: from ac.upc.es (fonoll.ac.upc.es [147.83.32.14]) by roura.ac.upc.es (8.11.0/8.11.0) with ESMTP id f4NF5F402460 for ; Wed, 23 May 2001 17:05:15 +0200 (MET DST) Message-ID: <3B0BD1AB.EBB09874@ac.upc.es> Date: Wed, 23 May 2001 17:05:15 +0200 From: Eduard Santamaria Organization: DAC-UPC X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: pro64-support@oss.sgi.com Subject: Download release 0.12 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pro64-support@oss.sgi.com Precedence: bulk I've seen this question on the mailing list archive, but no response yet. It seems that since you upgraded to release 0.13 you removed the previous release from the web, but r0.13 won't work properly with NUE. Is there any way to get the Pro64 0.12 rpm? Thanks. _____________________________________________________________________ o o o Eduard Santamaria Barnadas o o o Department of Computer Architecture o o o Universitat Politecnica de Catalunya Phone: +34 934 011 649 C/ Jordi Girona, 1-3 Campus Nord, Modul C6 - S103 U P C 08034 - BARCELONA (SPAIN) mailto:esantama@ac.upc.es _____________________________________________________________________ From owner-pro64-support@oss.sgi.com Thu May 24 21:19:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4P4JYw16712 for pro64-support-outgoing; Thu, 24 May 2001 21:19:34 -0700 Received: from scapa.cs.ualberta.ca (root@scapa.cs.ualberta.ca [129.128.4.44]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4P4JXF16709 for ; Thu, 24 May 2001 21:19:33 -0700 Received: (from localhost user: 'pengzhao' uid#483 fake: STDIN (pengzhao@peers)) by scapa.cs.ualberta.ca id ; Thu, 24 May 2001 22:19:22 -0600 Date: Thu, 24 May 2001 22:19:22 -0600 (MDT) From: Peng Zhao To: sgi Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Hi, I noticed that Pro64 make several instrumentations during the backend phase (e.g. just before VHO, before LNO, before WOPT and cg etc). Is it because that transformation makes the annotation imprecise and we need to read the profiling result again? How to ensure the profiling result compatible with the transformed code? E.g, I want to do partial inlinining in the backend phase. And my initial plan of doing it is just after the first annotation (there still needs some more investigation for the feasibility, of course your suggestions are quite welcomed). After the partial inlining, the caller and callee change definitely. Is there any problem that later annotation? I guess the problem exists for other optimizations.In current Pro64, how the similar problems are addressed? Thanks. -- Regards Peng Peng Zhao pengzhao@cs.ualberta.ca http://www.cs.ualberta.ca/~pengzhao TEL (Lab): (780)492-3725 Lab: CSC251 From owner-pro64-support@oss.sgi.com Thu May 24 21:21:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4P4L0u16807 for pro64-support-outgoing; Thu, 24 May 2001 21:21:00 -0700 Received: from scapa.cs.ualberta.ca (root@scapa.cs.ualberta.ca [129.128.4.44]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4P4KxF16804 for ; Thu, 24 May 2001 21:20:59 -0700 Received: (from localhost user: 'pengzhao' uid#483 fake: STDIN (pengzhao@peers)) by scapa.cs.ualberta.ca id ; Thu, 24 May 2001 22:20:47 -0600 Date: Thu, 24 May 2001 22:20:46 -0600 (MDT) From: Peng Zhao To: sgi Subject: several times of instrumentation? (sorry for the previous email without title) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Hi, I noticed that Pro64 make several instrumentations during the backend phase (e.g. just before VHO, before LNO, before WOPT and cg etc). Is it because that transformation makes the annotation imprecise and we need to read the profiling result again? How to ensure the profiling result compatible with the transformed code? E.g, I want to do partial inlinining in the backend phase. And my initial plan of doing it is just after the first annotation (there still needs some more investigation for the feasibility, of course your suggestions are quite welcomed). After the partial inlining, the caller and callee change definitely. Is there any problem that later annotation? I guess the problem exists for other optimizations.In current Pro64, how the similar problems are addressed? Thanks. -- Regards Peng Peng Zhao pengzhao@cs.ualberta.ca http://www.cs.ualberta.ca/~pengzhao TEL (Lab): (780)492-3725 Lab: CSC251 From owner-pro64-support@oss.sgi.com Thu May 24 21:23:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4P4Ncc16952 for pro64-support-outgoing; Thu, 24 May 2001 21:23:38 -0700 Received: from pilsener.srv.ualberta.ca (pilsener.srv.ualberta.ca [129.128.5.19]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4P4NbF16949 for ; Thu, 24 May 2001 21:23:38 -0700 Received: from webmail.ualberta.ca (webmail.srv.ualberta.ca [129.128.5.67]) by pilsener.srv.ualberta.ca (8.11.1/8.11.1) with ESMTP id f4P4NVD03772; Thu, 24 May 2001 22:23:31 -0600 (MDT) X-WebMail-UserID: pzhao Date: Thu, 24 May 2001 22:21:42 -0600 From: pzhao To: Eduard Santamaria , pro64-support X-EXP32-SerialNo: 00003228 Subject: RE: Download release 0.12 Message-ID: <3B0EEA42@webmail.ualberta.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: WebMail (Hydra) SMTP v3.61.08 Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Fortunately, I have a backup tarball. But my root direcotory for web is not sufficent to hold it. tell me a place to upload it. thanks. >===== Original Message From Eduard Santamaria ===== >I've seen this question on the mailing list archive, but no response >yet. > >It seems that since you upgraded to release 0.13 you removed the >previous release from the web, but r0.13 won't work properly with >NUE. Is there any way to get the Pro64 0.12 rpm? > >Thanks. > >_____________________________________________________________________ > > o o o Eduard Santamaria Barnadas > o o o Department of Computer Architecture > o o o Universitat Politecnica de Catalunya Phone: +34 934 011 649 > C/ Jordi Girona, 1-3 > Campus Nord, Modul C6 - S103 > U P C 08034 - BARCELONA (SPAIN) mailto:esantama@ac.upc.es >_____________________________________________________________________ From owner-pro64-support@oss.sgi.com Fri May 25 18:37:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4Q1bKv20775 for pro64-support-outgoing; Fri, 25 May 2001 18:37:20 -0700 Received: from mail.eecis.udel.edu (louie.udel.edu [128.175.2.33]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4Q1bKF20772 for ; Fri, 25 May 2001 18:37:20 -0700 Received: from louie.udel.edu by mail.eecis.udel.edu id aa04668; 25 May 2001 21:36 EDT Date: Fri, 25 May 2001 21:36:28 -0400 (EDT) From: Haiping Wu To: pro64-support@oss.sgi.com MMDF-Warning: Parse error in original version of preceding line at mail.eecis.udel.edu Subject: preg Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Before lowering the whirl,every parameter has been assigned a preg(from r127,r126,...). I try to know which files do this work and which files describe the relative data structures and constants? --Haiping Wu From owner-pro64-support@oss.sgi.com Fri May 25 19:28:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4Q2SdF21557 for pro64-support-outgoing; Fri, 25 May 2001 19:28:39 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4Q2ScF21554 for ; Fri, 25 May 2001 19:28:39 -0700 Received: from gaea.engr.sgi.com (gaea.engr.sgi.com [130.62.180.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id TAA01247 for ; Fri, 25 May 2001 19:28:41 -0700 (PDT) mail_from (murthy@gaea.engr.sgi.com) Received: (from murthy@localhost) by gaea.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id TAA97514; Fri, 25 May 2001 19:26:02 -0700 (PDT) Date: Fri, 25 May 2001 19:26:02 -0700 (PDT) From: murthy@gaea.engr.sgi.com (Chandrasekhar Murthy) Message-Id: <200105260226.TAA97514@gaea.engr.sgi.com> To: pro64-support@oss.sgi.com, Haiping Wu Subject: Re: preg Sender: owner-pro64-support@oss.sgi.com Precedence: bulk > Before lowering the whirl,every parameter has been assigned a preg(from > r127,r126,...). I try to know which files do this work and which files > describe the relative data structures and constants? > > --Haiping Wu I think the information you want is in common/com/ia64/targ_sim.cxx Murthy From owner-pro64-support@oss.sgi.com Tue May 29 13:06:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4TK6OM11160 for pro64-support-outgoing; Tue, 29 May 2001 13:06:24 -0700 Received: from scapa.cs.ualberta.ca (root@scapa.cs.ualberta.ca [129.128.4.44]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4TK6Fd11157 for ; Tue, 29 May 2001 13:06:16 -0700 Received: (from localhost user: 'pengzhao' uid#483 fake: STDIN (pengzhao@peers)) by scapa.cs.ualberta.ca id ; Tue, 29 May 2001 14:05:50 -0600 Date: Tue, 29 May 2001 14:05:50 -0600 (MDT) From: Peng Zhao To: "Chan, Sun C" cc: sgi Subject: RE: several times of instrumentation? (sorry for the previous ema il without title) In-Reply-To: <9287DC1579B0D411AA2F009027F44C3F042DFACE@FMSMSX41> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pro64-support@oss.sgi.com Precedence: bulk On Tue, 29 May 2001, Chan, Sun C wrote: > > > > -----Original Message----- > > From: Peng Zhao [mailto:pengzhao@cs.ualberta.ca] > > Sent: Thursday, May 24, 2001 9:21 PM > > To: sgi > > Subject: several times of instrumentation? (sorry for the > > previous email > > without title) > > > > > > > > Hi, > > > > I noticed that Pro64 make several instrumentations during the > > backend phase (e.g. just before VHO, before LNO, before WOPT > > and cg etc). > > Is it because that transformation makes the annotation > > imprecise and we > > need to read the profiling result again? How to ensure the profiling > > result compatible with the transformed code? > > In fact, the correct phrase should be Pro64 "can" instrument > during the phases you mentioned (not cg though). In reality, it does > that before VHO. The design is so that you can do it in any phase. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ So, there are still possibilities that the feedback information is read in the later phase than VHO. Am I right? Does this implies that the instrumentation conducted in the first compilation must happen at the same phase of the annotation in the second compilation? And the instrumentation or annotation can only take place once during the compilation, although Pro64 can do it in several phases. Right? You mean that the instrumentation or annotation is only conducted before VHO even when various optimization flags are switched on(i.e. other calls in later phases to annotation are never invoked)? > > > > > E.g, I want to do partial inlinining in the backend > > phase. And my > > initial plan of doing it is just after the first annotation > > (there still > > needs some more investigation for the feasibility, of course your > > suggestions are quite welcomed). After the partial > > You meant during IPA? No. in the VHO phase ( just before the lowering from VH whirl to H whirl). It is after the annotation. > > > inlining, the caller and callee change definitely. Is there > > any problem > > that later annotation? > > The question is how you update the info after partial inlining. Since its > a form of cloning, you need to make some guestimation. The feedback is > designed for being able to verify before and after each optimization and > assert that the information is still "consistent". The update heuristic > is strictly up to the optimization phase since each has its own peculiar > requirement and hence different ways to deal with it. Pro64 can also > do some minor patching when annotation is inconsistent. When it cannot > patch, > it will invalidate a portion of the information. > > I guess the problem exists for other optimizations.In current Pro64, > > how the similar problems are addressed? > > > > Thanks. > > -- Regards Peng Peng Zhao pengzhao@cs.ualberta.ca http://www.cs.ualberta.ca/~pengzhao TEL (Lab): (780)492-3725 Lab: CSC251 From owner-pro64-support@oss.sgi.com Tue May 29 16:19:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4TNJBj14830 for pro64-support-outgoing; Tue, 29 May 2001 16:19:11 -0700 Received: from hypnos.cps.intel.com (hypnos.cps.intel.com [192.198.165.17]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4TNJ5h14824 for ; Tue, 29 May 2001 16:19:05 -0700 Received: from SMTP (fmsmsxvs01-1.fm.intel.com [132.233.42.201]) by hypnos.cps.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.39 2001/05/18 00:47:02 root Exp $) with SMTP id SAA09528; Tue, 29 May 2001 18:57:39 GMT Received: from fmsmsx27.FM.INTEL.COM ([132.233.48.27]) by 132.233.48.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Tue, 29 May 2001 18:49:03 0000 (GMT) Received: by fmsmsx27.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 29 May 2001 11:49:01 -0700 Message-ID: <9287DC1579B0D411AA2F009027F44C3F042DFACE@FMSMSX41> From: "Chan, Sun C" To: "'Peng Zhao'" , sgi Subject: RE: several times of instrumentation? (sorry for the previous ema il without title) Date: Tue, 29 May 2001 11:48:58 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-pro64-support@oss.sgi.com Precedence: bulk > -----Original Message----- > From: Peng Zhao [mailto:pengzhao@cs.ualberta.ca] > Sent: Thursday, May 24, 2001 9:21 PM > To: sgi > Subject: several times of instrumentation? (sorry for the > previous email > without title) > > > > Hi, > > I noticed that Pro64 make several instrumentations during the > backend phase (e.g. just before VHO, before LNO, before WOPT > and cg etc). > Is it because that transformation makes the annotation > imprecise and we > need to read the profiling result again? How to ensure the profiling > result compatible with the transformed code? In fact, the correct phrase should be Pro64 "can" instrument during the phases you mentioned (not cg though). In reality, it does that before VHO. The design is so that you can do it in any phase. > > E.g, I want to do partial inlinining in the backend > phase. And my > initial plan of doing it is just after the first annotation > (there still > needs some more investigation for the feasibility, of course your > suggestions are quite welcomed). After the partial You meant during IPA? > inlining, the caller and callee change definitely. Is there > any problem > that later annotation? The question is how you update the info after partial inlining. Since its a form of cloning, you need to make some guestimation. The feedback is designed for being able to verify before and after each optimization and assert that the information is still "consistent". The update heuristic is strictly up to the optimization phase since each has its own peculiar requirement and hence different ways to deal with it. Pro64 can also do some minor patching when annotation is inconsistent. When it cannot patch, it will invalidate a portion of the information. > I guess the problem exists for other optimizations.In current Pro64, > how the similar problems are addressed? > > Thanks. From owner-pro64-support@oss.sgi.com Tue May 29 19:32:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4U2WNq18970 for pro64-support-outgoing; Tue, 29 May 2001 19:32:23 -0700 Received: from ganymede.or.intel.com (jffdns01.or.intel.com [134.134.248.3]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4U2WGh18963 for ; Tue, 29 May 2001 19:32:17 -0700 Received: from SMTP (orsmsxvs02-1.jf.intel.com [192.168.65.201]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.39 2001/05/18 00:47:02 root Exp $) with SMTP id CAA19674; Wed, 30 May 2001 02:32:07 GMT Received: from orsmsx28.jf.intel.com ([192.168.70.28]) by 192.168.70.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 30 May 2001 02:32:04 0000 (GMT) Received: by orsmsx28.jf.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 29 May 2001 19:32:02 -0700 Message-ID: <9287DC1579B0D411AA2F009027F44C3F042DFAD8@FMSMSX41> From: "Chan, Sun C" To: "'Peng Zhao'" Cc: sgi Subject: RE: several times of instrumentation? (sorry for the previous ema il without title) Date: Tue, 29 May 2001 17:44:06 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-pro64-support@oss.sgi.com Precedence: bulk > -----Original Message----- > From: Peng Zhao [mailto:pengzhao@cs.ualberta.ca] > Sent: Tuesday, May 29, 2001 1:06 PM > To: Chan, Sun C > Cc: sgi > ... > > In fact, the correct phrase should be Pro64 "can" instrument > > during the phases you mentioned (not cg though). In > reality, it does > > that before VHO. The design is so that you can do it in any phase. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > So, there are still possibilities that the feedback > information is read in the later phase than VHO. Am I right? Does this > implies that the instrumentation conducted in the first > compilation must > happen at the same phase of the annotation in the second compilation? Yes to both questions. > And the instrumentation or annotation can only take place > once during the > compilation, although Pro64 can do it in several phases. Right? Yes > > You mean that the instrumentation or annotation is only > conducted > before VHO even when various optimization flags are switched > on(i.e. other calls in later phases to annotation are never invoked)? As far as I know, that's case. > > > > > > > > > > E.g, I want to do partial inlinining in the backend > > > phase. And my > > > initial plan of doing it is just after the first annotation > > > (there still > > > needs some more investigation for the feasibility, of course your > > > suggestions are quite welcomed). After the partial > > > > You meant during IPA? > > No. in the VHO phase ( just before the lowering from VH whirl to H > whirl). It is after the annotation. If you do this right after VHO, you are losing the benefit of Preopt which in general is designed to normalize/cleanup a lot of code hence one can make a better inlining decision among other benefits. The reason I asked if you are doing partial inlining during IPA is that inlining is done at IPA time. If you have a partial inlining phase after VHO, how does that interact with the inlining part of IPA? Also, things like const. prop in IPA helps cleaning up code for better inlining/partial inlining decisions. Incidentally, Preopt is ran before IPA. > > > > > > inlining, the caller and callee change definitely. Is there > > > any problem > > > that later annotation? > > > > The question is how you update the info after partial > inlining. Since its > > a form of cloning, you need to make some guestimation. The > feedback is > > designed for being able to verify before and after each > optimization and > > assert that the information is still "consistent". The > update heuristic > > is strictly up to the optimization phase since each has its > own peculiar > > requirement and hence different ways to deal with it. Pro64 can also > > do some minor patching when annotation is inconsistent. > When it cannot > > patch, > > it will invalidate a portion of the information. > > > I guess the problem exists for other optimizations.In > current Pro64, > > > how the similar problems are addressed? > > > > > > Thanks. > > > > > > -- > Regards > > Peng > Peng Zhao pengzhao@cs.ualberta.ca > http://www.cs.ualberta.ca/~pengzhao > TEL (Lab): (780)492-3725 Lab: CSC251 > > > From owner-pro64-support@oss.sgi.com Tue May 29 20:22:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4U3Mls19781 for pro64-support-outgoing; Tue, 29 May 2001 20:22:47 -0700 Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4U3Mih19778 for ; Tue, 29 May 2001 20:22:44 -0700 Received: from SMTP (fmsmsxvs03-1.fm.intel.com [132.233.42.203]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.39 2001/05/18 00:47:02 root Exp $) with SMTP id DAA27720 for ; Wed, 30 May 2001 03:22:33 GMT Received: from fmsmsx19.fm.intel.com ([132.233.48.19]) by 132.233.48.203 (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 30 May 2001 03:22:33 0000 (GMT) Received: by fmsmsx19.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 29 May 2001 20:22:32 -0700 Received: from fmsmsxfw01.fm.intel.com ([192.168.133.200]) by fmsmsx27.FM.INTEL.COM with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LYYG2K2B; Tue, 29 May 2001 20:19:28 -0700 Received: by ldap.intel.com with Internet Mail Service (5.5.2650.21) id ; Wed, 30 May 2001 11:32:49 +0800 Message-ID: From: "Tuo, Tony" To: "'pro64-support@oss.sgi.com'" Subject: Make Pro64 0.13 run under nue-1.0-1 Date: Wed, 30 May 2001 09:57:29 +0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-pro64-support@oss.sgi.com Precedence: bulk With help from Murthy(@sgi), Ken(@sgi) and Peng(@ualberta), now I can make Pro64 0.13 run under nue-1.0-1. It passed an initial test of about 400 test cases. I didn't run into GLIBC2.2 problem with my configuration. System configuration: .RedHat 6.2 .GCC 2.95.2 Steps: 1. install nue-1.0-1, nue-fs-1.0-1 and ski-0.8731-1. 2. start nue and install pro64-0.01-12.ia64.rpm. Compile a program, run it and accept the license agreement. Without this step, a message "can't execute binary" appears when running programs built with pro64 013. 3. Get pro64 013 source and apply below changes(Thanks to Murthy, Ken and Peng for their advice on these changes): .The definition of V_PF_FLAGS in variants.h should have the ULL suffix as indicated below #define V_PF_FLAGS 0xffffffff00000000ULL /* Prefetch flags */ .change osprey1.0/g++fe/gnu/tree.h line 1457 to #define DECL_BUILT_IN(NODE) (!(DECL_BUILT_IN_CLASS (NODE) == NOT_BUILT_IN)) .change osprey1.0/gccfe/gnu/tree.h line 1494 to #define DECL_BUILT_IN(NODE) (!(DECL_BUILT_IN_CLASS (NODE) == NOT_BUILT_IN)) 4. Get version 2.9-ia64-000717 of the ia64 assembler 'as' and copy it into nue/usr/bin. I copied this assembler from nue1.2 which can be downloaded from hp. Without this version of the assembler, several pseudo ops such as .copy_state, .label_state and .restorereg can't be recognized by the old assembler 2.9-ia64-000212. 5. Now it's time to build pro64 0.13 following the building instructions. IA64 native library can also be built under nue with the updated assembler. NUE 1.2 can be found at http://www.software.hp.com/products/LIA64. Any comments are welcome. Thanks. Tony From owner-pro64-support@oss.sgi.com Wed May 30 06:35:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4UDZAR28517 for pro64-support-outgoing; Wed, 30 May 2001 06:35:10 -0700 Received: from hotmail.com (f209.law14.hotmail.com [64.4.21.209]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4UDZ8h28512 for ; Wed, 30 May 2001 06:35:08 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 30 May 2001 06:35:02 -0700 Received: from 159.226.40.178 by lw14fd.law14.hotmail.msn.com with HTTP; Wed, 30 May 2001 13:35:02 GMT X-Originating-IP: [159.226.40.178] From: "Yanjun HU" To: pro64-support@oss.sgi.com Subject: Problem with "sgicc -ipa filename.c" Date: Wed, 30 May 2001 21:35:02 +0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 30 May 2001 13:35:02.0805 (UTC) FILETIME=[54825C50:01C0E90D] Sender: owner-pro64-support@oss.sgi.com Precedence: bulk hi, I want to get the Call_Graph at the phase of ipa(I add some code in ipa_main.cxx,build and get the file "ipa.so").But when I use "sgicc -ipa filename.c" I got the following error message: sgicc ERROR: cannot exec /usr/pro64/ipa_link I have no idea where the file "ipa_link" is from and when I should build this file. For there are no this file installed in the "INSTALL" file. Can anyone tell me the answer. 3x! Regards, Hu Yanjun _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From owner-pro64-support@oss.sgi.com Wed May 30 12:18:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4UJIgI14799 for pro64-support-outgoing; Wed, 30 May 2001 12:18:42 -0700 Received: from hypnos.cps.intel.com (hypnos.cps.intel.com [192.198.165.17]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4UJIah14795 for ; Wed, 30 May 2001 12:18:36 -0700 Received: from SMTP (fmsmsxvs01-1.fm.intel.com [132.233.42.201]) by hypnos.cps.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.39 2001/05/18 00:47:02 root Exp $) with SMTP id EAA28490 for ; Wed, 30 May 2001 04:04:37 GMT Received: from fmsmsx27.FM.INTEL.COM ([132.233.48.27]) by 132.233.48.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 30 May 2001 04:00:55 0000 (GMT) Received: by fmsmsx27.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 29 May 2001 21:00:53 -0700 Message-ID: <9287DC1579B0D411AA2F009027F44C3F09E40264@FMSMSX41> From: "Chan, Sun C" To: "Tuo, Tony" , "'pro64-support@oss.sgi.com'" Subject: RE: Make Pro64 0.13 run under nue-1.0-1 Date: Tue, 29 May 2001 21:00:33 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-pro64-support@oss.sgi.com Precedence: bulk I thought there is some glitch running binary produced with -ipa on nue? Sun > -----Original Message----- > From: Tuo, Tony [mailto:tony.tuo@intel.com] > Sent: Tuesday, May 29, 2001 6:57 PM > To: 'pro64-support@oss.sgi.com' > Subject: Make Pro64 0.13 run under nue-1.0-1 > > > With help from Murthy(@sgi), Ken(@sgi) and Peng(@ualberta), > now I can make Pro64 0.13 run under nue-1.0-1. It passed an > initial test of about 400 test cases. I didn't run into > GLIBC2.2 problem with my configuration. > > System configuration: > .RedHat 6.2 > .GCC 2.95.2 > > Steps: > 1. install nue-1.0-1, nue-fs-1.0-1 and ski-0.8731-1. > > 2. start nue and install pro64-0.01-12.ia64.rpm. Compile a > program, run it and accept the license agreement. Without > this step, a message "can't execute binary" appears when > running programs built with pro64 013. > > 3. Get pro64 013 source and apply below changes(Thanks to > Murthy, Ken and Peng for their advice on these changes): > .The definition of V_PF_FLAGS in variants.h should have > the ULL suffix as indicated below > #define V_PF_FLAGS > 0xffffffff00000000ULL /* Prefetch flags */ > .change osprey1.0/g++fe/gnu/tree.h line 1457 to > #define DECL_BUILT_IN(NODE) > (!(DECL_BUILT_IN_CLASS (NODE) == NOT_BUILT_IN)) > .change osprey1.0/gccfe/gnu/tree.h line 1494 to > #define DECL_BUILT_IN(NODE) > (!(DECL_BUILT_IN_CLASS (NODE) == NOT_BUILT_IN)) > > 4. Get version 2.9-ia64-000717 of the ia64 assembler 'as' and > copy it into nue/usr/bin. I copied this assembler from nue1.2 > which can be downloaded from hp. Without this version of the > assembler, several pseudo ops such as .copy_state, > .label_state and .restorereg can't be recognized by the old > assembler 2.9-ia64-000212. > > 5. Now it's time to build pro64 0.13 following the building > instructions. IA64 native library can also be built under nue > with the updated assembler. > > NUE 1.2 can be found at http://www.software.hp.com/products/LIA64. > > Any comments are welcome. > > Thanks. > Tony > > From owner-pro64-support@oss.sgi.com Wed May 30 21:06:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4V46P629129 for pro64-support-outgoing; Wed, 30 May 2001 21:06:25 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4V46Mh29125 for ; Wed, 30 May 2001 21:06:22 -0700 Received: from ganymede.or.intel.com (jffdns01.or.intel.com [134.134.248.3]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id VAA05260 for ; Wed, 30 May 2001 21:06:20 -0700 (PDT) mail_from (dagen.wang@intel.com) Received: from SMTP (orsmsxvs02-1.jf.intel.com [192.168.65.201]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.39 2001/05/18 00:47:02 root Exp $) with SMTP id EAA13679 for ; Thu, 31 May 2001 04:06:19 GMT Received: from orsmsx28.jf.intel.com ([192.168.70.28]) by 192.168.70.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 31 May 2001 04:06:18 0000 (GMT) Received: by orsmsx28.jf.intel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 30 May 2001 21:06:17 -0700 Received: from fmsmsxfw01.fm.intel.com ([192.168.133.200]) by fmsmsx27.FM.INTEL.COM with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id L9T2K0P6; Wed, 30 May 2001 20:10:36 -0700 Received: by ldap.intel.com with Internet Mail Service (5.5.2650.21) id ; Thu, 31 May 2001 11:23:57 +0800 Message-ID: From: "Wang, Dagen" To: pro64-support@oss.sgi.com Subject: necessary presteps to run ipa of pro64 Date: Thu, 31 May 2001 11:10:33 +0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Description: ipa applications need to reference a lib ld-linux-ia64.so.2, so what we should do is:add a link ld-linux-ia64.so.2 to ld-2.1.3. Steps: 1. nue(suppose on nue environment) 2. su 3. cd /lib 4. ln -s ld-2.1.3.so ld-linux-ia64.so.2 dagen From owner-pro64-support@oss.sgi.com Thu May 31 18:52:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f511qsn02300 for pro64-support-outgoing; Thu, 31 May 2001 18:52:54 -0700 Received: from ganymede.or.intel.com (jffdns01.or.intel.com [134.134.248.3]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f511qoh02294 for ; Thu, 31 May 2001 18:52:50 -0700 Received: from SMTP (orsmsxvs02-1.jf.intel.com [192.168.65.201]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.39 2001/05/18 00:47:02 root Exp $) with SMTP id BAA24578 for ; Fri, 1 Jun 2001 01:52:45 GMT Received: from orsmsx28.jf.intel.com ([192.168.70.28]) by 192.168.70.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Fri, 01 Jun 2001 01:52:45 0000 (GMT) Received: by orsmsx28.jf.intel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 31 May 2001 18:52:43 -0700 Received: from fmsmsxfw01.fm.intel.com ([192.168.133.200]) by fmsmsx27.FM.INTEL.COM with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id MAQPWKZ7; Thu, 31 May 2001 18:52:38 -0700 Received: by ldap.intel.com with Internet Mail Service (5.5.2650.21) id ; Fri, 1 Jun 2001 09:55:51 +0800 Message-ID: From: "Wang, Dagen" To: "'pro64-support@oss.sgi.com'" Subject: Can not dump the .I files in ipa_keep directory using ir_b2a or w hirl2c Date: Fri, 1 Jun 2001 09:51:37 +0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Hi: I tried to dump the .I files in the ipa_keep directory using ir_b2a or whirl2c. Yet it reports: ### Compiler Error during Reading WHIRL file phase: ### Can't read strtab section in intermediate compiler file 1.I Do I miss something or add some parameters? Thanks. dagen From owner-pro64-support@oss.sgi.com Thu May 31 19:14:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f512E3k05935 for pro64-support-outgoing; Thu, 31 May 2001 19:14:03 -0700 Received: from calliope1.fm.intel.com (fmfdns01.fm.intel.com [132.233.247.10]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f512E0h05928 for ; Thu, 31 May 2001 19:14:00 -0700 Received: from fmsmsx29.FM.INTEL.COM (fmsmsx29.fm.intel.com [132.233.42.29]) by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.39 2001/05/18 00:47:02 root Exp $) with ESMTP id CAA20152; Fri, 1 Jun 2001 02:13:42 GMT Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 31 May 2001 19:13:40 -0700 Received: from fmsmsxfw01.fm.intel.com ([192.168.133.200]) by fmsmsx27.FM.INTEL.COM with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id MAQPWNR3; Thu, 31 May 2001 19:13:38 -0700 Received: by ldap.intel.com with Internet Mail Service (5.5.2650.21) id ; Fri, 1 Jun 2001 10:16:51 +0800 Message-ID: From: "Wang, Dagen" To: "'Yanjun HU'" , pro64-support@oss.sgi.com Subject: RE: Problem with "sgicc -ipa filename.c" Date: Fri, 1 Jun 2001 10:11:56 +0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-pro64-support@oss.sgi.com Precedence: bulk We have also met such problems. In fact, if upgrade to pro64 .13, you will not have such problems. dagen -----Original Message----- From: Yanjun HU [mailto:huyanjun79@hotmail.com] Sent: 2001å¹´5æoe^30æ-¥ 21:35 To: pro64-support@oss.sgi.com Subject: Problem with "sgicc -ipa filename.c" hi, I want to get the Call_Graph at the phase of ipa(I add some code in ipa_main.cxx,build and get the file "ipa.so").But when I use "sgicc -ipa filename.c" I got the following error message: sgicc ERROR: cannot exec /usr/pro64/ipa_link I have no idea where the file "ipa_link" is from and when I should build this file. For there are no this file installed in the "INSTALL" file. Can anyone tell me the answer. 3x! Regards, Hu Yanjun _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.