From owner-pro64-support@oss.sgi.com Fri Jun 1 07:56:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f51Eul326460 for pro64-support-outgoing; Fri, 1 Jun 2001 07:56:47 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f51Eukh26457 for ; Fri, 1 Jun 2001 07:56:46 -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 HAA24089 for ; Fri, 1 Jun 2001 07:56:46 -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 HAA94485; Fri, 1 Jun 2001 07:54:10 -0700 (PDT) Date: Fri, 1 Jun 2001 07:54:10 -0700 (PDT) From: murthy@gaea.engr.sgi.com (Chandrasekhar Murthy) Message-Id: <200106011454.HAA94485@gaea.engr.sgi.com> To: "'pro64-support@oss.sgi.com'" , "Wang, Dagen" Subject: Re: Can not dump the .I files in ipa_keep directory using ir_b2a or w hirl2c Sender: owner-pro64-support@oss.sgi.com Precedence: bulk You might also need to specify -sym symtab.G Murthy From owner-pro64-support@oss.sgi.com Fri Jun 1 10:23:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f51HNe402561 for pro64-support-outgoing; Fri, 1 Jun 2001 10:23:40 -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 f51HNch02555 for ; Fri, 1 Jun 2001 10:23:38 -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 KAA09244 for ; Fri, 1 Jun 2001 10:23:37 -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 KAA23927; Fri, 1 Jun 2001 10:19:48 -0700 (PDT) Date: Fri, 1 Jun 2001 10:19:48 -0700 (PDT) From: mpm@rohi.engr.sgi.com (Michael Murphy) Message-Id: <200106011719.KAA23927@rohi.engr.sgi.com> To: "'pro64-support@oss.sgi.com'" , "Wang, Dagen" Subject: Re: Can not dump the .I files in ipa_keep directory using ir_b2a or w hirl2c Sender: owner-pro64-support@oss.sgi.com Precedence: bulk For ipa, the global symbol table is put in a separate file, symtab.G, so you have to specify that along with the .I file: ir_b2a -sym symtab.G 1.I -- Mike Murphy -- mpm@sgi.com -- quote of the day: -- "A great marriage is not when the "perfect couple" comes together. -- It is when an imperfect couple learns to enjoy their differences." -- (Dave Meurer) From owner-pro64-support@oss.sgi.com Mon Jun 4 12:42:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f54JgAH26669 for pro64-support-outgoing; Mon, 4 Jun 2001 12:42:10 -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 SMTP id f54Jg9h26658 for ; Mon, 4 Jun 2001 12:42:09 -0700 Received: from liao.capsl.udel.edu (liao.capsl.udel.edu [128.4.10.34]) by olsen.capsl.udel.edu (8.9.1/8.9.1) with ESMTP id PAA19129 for ; Mon, 4 Jun 2001 15:42:07 -0400 (EDT) Date: Mon, 4 Jun 2001 15:42:06 -0400 (EDT) From: Hongbo Yang To: Subject: Fortran 90 compiler Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Which Fortran90 compiler should I use to compile the fortran FE? I got some Fortran compiler to compile fold.f, However, the -MD option in osprey1.0/crayf90/fe90/Makefile.gbase is not recognized, and it complains that the continuation lines( 259-284 ) too long. -------------------------------- Hongbo Yang Electrical Engineering Univ of Delaware From owner-pro64-support@oss.sgi.com Tue Jun 5 00:14:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f557Egf19372 for pro64-support-outgoing; Tue, 5 Jun 2001 00:14:42 -0700 Received: from hotmail.com (f202.law14.hotmail.com [64.4.21.202]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f557Efh19369 for ; Tue, 5 Jun 2001 00:14:41 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 5 Jun 2001 00:14:35 -0700 Received: from 159.226.40.178 by lw14fd.law14.hotmail.msn.com with HTTP; Tue, 05 Jun 2001 07:14:35 GMT X-Originating-IP: [159.226.40.178] From: "Yanjun HU" To: hyang@capsl.udel.edu Cc: pro64-support@oss.sgi.com Subject: Re: Fortran 90 compiler Date: Tue, 05 Jun 2001 15:14:35 +0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 05 Jun 2001 07:14:35.0964 (UTC) FILETIME=[2D2157C0:01C0ED8F] Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Hi, please see the NOTE of README.src in the build of Fortran 90 Front-End: NOTE:mfef90 does not build at this time because it needs an IA-32 version of f90 to compile parts os itself. While SGI has a prototype of such a compiler,it is good enough only to compile what is needed and thus we are not making it available. Mfef90 contains only code developed by SGI. I encounter the same problem while building the Front-End (file fold.f). I tried a lot of f90 compilers. But they all make no effects. I have no idea where to get a correct f90 compiler till now.:( Hu Yanjun Institute of Computing Technology, Chinese Academy of Sciences ----Original Message Follows---- From: Hongbo Yang To: Subject: Fortran 90 compiler Date: Mon, 4 Jun 2001 15:42:06 -0400 (EDT) Which Fortran90 compiler should I use to compile the fortran FE? I got some Fortran compiler to compile fold.f, However, the -MD option in osprey1.0/crayf90/fe90/Makefile.gbase is not recognized, and it complains that the continuation lines( 259-284 ) too long. -------------------------------- Hongbo Yang Electrical Engineering Univ of Delaware _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From owner-pro64-support@linux-xfs.sgi.com Fri Jun 8 14:35:25 2001 Received: (from mail@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f58LZPVI027455 for pro64-support-outgoing; Fri, 8 Jun 2001 14:35:25 -0700 X-Authentication-Warning: linux-xfs.sgi.com: mail set sender to owner-pro64-support@oss.sgi.com using -f Received: from scapa.cs.ualberta.ca (root@scapa.cs.ualberta.ca [129.128.4.44]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f58LZB3D027436 for ; Fri, 8 Jun 2001 14:35:14 -0700 Received: (from localhost user: 'pengzhao' uid#483 fake: STDIN (pengzhao@peers)) by scapa.cs.ualberta.ca id ; Fri, 8 Jun 2001 15:35:05 -0600 Date: Fri, 8 Jun 2001 15:35:05 -0600 (MDT) From: Peng Zhao To: sgi Subject: CFG by daVinci (fwd) Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/Mixed; BOUNDARY="-2138965737-1998950407-991971410=:24742" Content-ID: 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-1998950407-991971410=:24742 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: Hi, I have a question about the CFG drew by daVinci. Enclosed are two files, one is a very simple c program and the other one is the corresponding CFG just after annotation. It is a little strange for me. First, block 2 and 4 should be one (basic block) and 3&5 too. Why draw them two separated blocks. What is the meaning of block 6 ( especially: the meanning of "-----")? Does it mean the "return" statement in the program? What does the block 7 stand for? BTW1: what is the relationship between the ID of each block in the CFG drew by daVinci and the corresponding BB_NODE->Id()? BTW2: What is COMMA, RCOMMA, MU and CHI? Thanks. -- Regards Peng Peng Zhao pengzhao@cs.ualberta.ca http://www.cs.ualberta.ca/~pengzhao TEL (Lab): (780)492-3725 Lab: CSC251 ---2138965737-1998950407-991971410=:24742 Content-Type: APPLICATION/POSTSCRIPT; NAME=xx Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: CFG(.ps) Content-Disposition: ATTACHMENT; FILENAME=xx JSFQUy1BZG9iZS0zLjAgRVBTRi0zLjAKJSVCb3VuZGluZ0JveDogMCAwIDIz OCA0MzcKJSVDcmVhdG9yOiBkYVZpbmNpIFYyLjEgKGluZm8gYXZhaWxhYmxl IGZyb20gZGFWaW5jaUBJbmZvcm1hdGlrLlVuaS1CcmVtZW4uREUpCiUlRm9y OiBwZW5nemhhb0BzYWt3YXRhbWF1IChQZW5nIFpoYW8pCiUlVGl0bGU6IAol JUNyZWF0aW9uRGF0ZTogVGh1IEp1biAgNyAyMToyNDowMiAyMDAxCgolJVBh Z2VzOiAxCiUlRG9jdW1lbnROZWVkZWRSZXNvdXJjZXM6CiUlKyBmb250IEx1 Y2lkYVNhbnMKJSUrIGZvbnQgTHVjaWRhU2Fucy1Cb2xkCiUlKyBmb250IEx1 Y2lkYVNhbnMtSXRhbGljCiUlKyBmb250IEx1Y2lkYVNhbnMtQm9sZEl0YWxp YwolJSsgZm9udCBUaW1lcy1Sb21hbgolJSsgZm9udCBUaW1lcy1Cb2xkCiUl KyBmb250IFRpbWVzLUl0YWxpYwolJSsgZm9udCBUaW1lcy1Cb2xkSXRhbGlj CiUlKyBmb250IEhlbHZldGljYQolJSsgZm9udCBIZWx2ZXRpY2EtQm9sZAol JSsgZm9udCBIZWx2ZXRpY2EtT2JsaXF1ZQolJSsgZm9udCBIZWx2ZXRpY2Et Qm9sZE9ibGlxdWUKJSUrIGZvbnQgSGVsdmV0aWNhLU5hcnJvdwolJSsgZm9u dCBIZWx2ZXRpY2EtTmFycm93LUJvbGQKJSUrIGZvbnQgSGVsdmV0aWNhLU5h cnJvdy1PYmxpcXVlCiUlKyBmb250IEhlbHZldGljYS1OYXJyb3ctQm9sZE9i bGlxdWUKJSUrIGZvbnQgQ291cmllcgolJSsgZm9udCBDb3VyaWVyLUJvbGQK JSUrIGZvbnQgQ291cmllci1PYmxpcXVlCiUlKyBmb250IENvdXJpZXItQm9s ZE9ibGlxdWUKJSUrIGZvbnQgWmFwZkNoYW5jZXJ5LU1lZGl1bUl0YWxpYwol JUVuZENvbW1lbnRzCgolJUJlZ2luUHJvbG9nCi9kYVZpbmNpX2RpY3QgMjAw IGRpY3QgZGVmCmRhVmluY2lfZGljdCBiZWdpbgovZm9udHNpemUgNiBkZWYK Ci9jcCAlIE5hbWVPZkZvbnRUb0JlQ29waWVkCnsgZmluZGZvbnQgZHVwIGxl bmd0aCBkaWN0IGJlZ2luIAogIHsgMSBpbmRleCAvRklEIG5lIHtkZWZ9IHtw b3AgcG9wfSBpZmVsc2V9IGZvcmFsbCAKICAvRW5jb2RpbmcgSVNPTGF0aW4x RW5jb2RpbmcgZGVmIGN1cnJlbnRkaWN0IGVuZCAKfSBkZWYKL3JuICUgTmFt ZU9mTmV3Rm9udFdpdGhJc29FbmNvZGluZwp7IGV4Y2ggZGVmaW5lZm9udCBw b3AgfSBkZWYKL3NmICUgTmFtZU9mRm9udFRvQmVTZXQKeyBmaW5kZm9udCBm b250c2l6ZSBzY2FsZWZvbnQgc2V0Zm9udCB9IGRlZgoKJSBDb3B5IGFsbCBm b250cyB0byBnZXQgSVNPIDgtYml0IGNoYXJzCi9UaW1lcy1Sb21hbiBjcCAv Rm9udFRpbWVzIHJuCi9UaW1lcy1Cb2xkIGNwIC9Gb250VGltZXNCb2xkIHJu Ci9UaW1lcy1JdGFsaWMgY3AgL0ZvbnRUaW1lc0l0YWxpYyBybgovVGltZXMt Qm9sZEl0YWxpYyBjcCAvRm9udFRpbWVzQm9sZEl0YWxpYyBybgovSGVsdmV0 aWNhLU5hcnJvdyBjcCAvRm9udEhlbHZldGljYU5hcnJvdyBybgovSGVsdmV0 aWNhLU5hcnJvdy1Cb2xkIGNwIC9Gb250SGVsdmV0aWNhTmFycm93Qm9sZCBy bgovSGVsdmV0aWNhLU5hcnJvdy1PYmxpcXVlIGNwIC9Gb250SGVsdmV0aWNh TmFycm93SXRhbGljIHJuCi9IZWx2ZXRpY2EtTmFycm93LUJvbGRPYmxpcXVl IGNwIC9Gb250SGVsdmV0aWNhTmFycm93Qm9sZEl0YWxpYyBybgovQ291cmll ciBjcCAvRm9udENvdXJpZXIgcm4KL0NvdXJpZXItQm9sZCBjcCAvRm9udENv dXJpZXJCb2xkIHJuCi9Db3VyaWVyLU9ibGlxdWUgY3AgL0ZvbnRDb3VyaWVy SXRhbGljIHJuCi9Db3VyaWVyLUJvbGRPYmxpcXVlIGNwIC9Gb250Q291cmll ckJvbGRJdGFsaWMgcm4KL0x1Y2lkYVNhbnMgY3AgL0ZvbnRMdWNpZGEgcm4K L0x1Y2lkYVNhbnMtQm9sZCBjcCAvRm9udEx1Y2lkYUJvbGQgcm4KL0x1Y2lk YVNhbnMtSXRhbGljIGNwIC9Gb250THVjaWRhSXRhbGljIHJuCi9MdWNpZGFT YW5zLUJvbGRJdGFsaWMgY3AgL0ZvbnRMdWNpZGFCb2xkSXRhbGljIHJuCi9I ZWx2ZXRpY2EgY3AgL0ZvbnRIZWx2ZXRpY2Egcm4KL0hlbHZldGljYS1Cb2xk IGNwIC9Gb250SGVsdmV0aWNhQm9sZCBybgovSGVsdmV0aWNhLU9ibGlxdWUg Y3AgL0ZvbnRIZWx2ZXRpY2FJdGFsaWMgcm4KL0hlbHZldGljYS1Cb2xkT2Js aXF1ZSBjcCAvRm9udEhlbHZldGljYUJvbGRJdGFsaWMgcm4KCiUgRGVmaW5l IGZvbnRzCi9mb250X3RpbWVzX25vcm1hbCB7IC9Gb250VGltZXMgc2YgfSBk ZWYKL2ZvbnRfdGltZXNfYm9sZCB7IC9Gb250VGltZXNCb2xkIHNmIH0gZGVm Ci9mb250X3RpbWVzX2l0YWxpYyB7IC9Gb250VGltZXNJdGFsaWMgc2YgfSBk ZWYKL2ZvbnRfdGltZXNfYm9sZF9pdGFsaWMgeyAvRm9udFRpbWVzQm9sZEl0 YWxpYyBzZiB9IGRlZgovZm9udF9oZWx2ZXRpY2Ffbm9ybWFsIHsgL0ZvbnRI ZWx2ZXRpY2FOYXJyb3cgc2YgfSBkZWYKL2ZvbnRfaGVsdmV0aWNhX2JvbGQg eyAvRm9udEhlbHZldGljYU5hcnJvd0JvbGQgc2YgfSBkZWYKL2ZvbnRfaGVs dmV0aWNhX2l0YWxpYyB7IC9Gb250SGVsdmV0aWNhTmFycm93SXRhbGljIHNm IH0gZGVmCi9mb250X2hlbHZldGljYV9ib2xkX2l0YWxpYyB7IC9Gb250SGVs dmV0aWNhTmFycm93Qm9sZEl0YWxpYyBzZiB9IGRlZgovZm9udF9jb3VyaWVy X25vcm1hbCB7IC9Gb250Q291cmllciBzZiB9IGRlZgovZm9udF9jb3VyaWVy X2JvbGQgeyAvRm9udENvdXJpZXJCb2xkIHNmIH0gZGVmCi9mb250X2NvdXJp ZXJfaXRhbGljIHsgL0ZvbnRDb3VyaWVySXRhbGljIHNmIH0gZGVmCi9mb250 X2NvdXJpZXJfYm9sZF9pdGFsaWMgeyAvRm9udENvdXJpZXJCb2xkSXRhbGlj IHNmIH0gZGVmCgolIFNwZWNpYWwgY2FzZTogdXNlIGZvbnQgSGVsdmV0aWNh LCBpZiBMdWNpZGEgaXMgbm90IHN1cHBvcnRlZAovZm9udF9sdWNpZGFfbm9y bWFsCnsgL0x1Y2lkYVNhbnMgZHVwIEZvbnREaXJlY3RvcnkgZXhjaCBrbm93 bgogIHsgL0ZvbnRMdWNpZGEgc2YgfSB7IC9Gb250SGVsdmV0aWNhIHNmIH0g aWZlbHNlIHBvcAp9IGRlZgovZm9udF9sdWNpZGFfYm9sZCAKeyAvTHVjaWRh U2Fucy1Cb2xkIGR1cCBGb250RGlyZWN0b3J5IGV4Y2gga25vd24KICB7IC9G b250THVjaWRhQm9sZCBzZiB9IHsgL0ZvbnRIZWx2ZXRpY2FCb2xkIHNmIH0g aWZlbHNlIHBvcAp9IGRlZgovZm9udF9sdWNpZGFfaXRhbGljIAp7IC9MdWNp ZGFTYW5zLUl0YWxpYyBkdXAgRm9udERpcmVjdG9yeSBleGNoIGtub3duCiAg eyAvRm9udEx1Y2lkYUl0YWxpYyBzZiB9IHsgL0ZvbnRIZWx2ZXRpY2FJdGFs aWMgc2YgfSBpZmVsc2UgcG9wCn0gZGVmCi9mb250X2x1Y2lkYV9ib2xkX2l0 YWxpYyAKeyAvTHVjaWRhU2Fucy1Cb2xkSXRhbGljIGR1cCBGb250RGlyZWN0 b3J5IGV4Y2gga25vd24KICB7IC9Gb250THVjaWRhQm9sZEl0YWxpYyBzZiB9 IHsgL0ZvbnRIZWx2ZXRpY2FCb2xkSXRhbGljIHNmIH0gaWZlbHNlIHBvcAp9 IGRlZgoKL3doaXRlIHsxIDEgMSBzZXRyZ2Jjb2xvcn0gZGVmCi9ibGFjayB7 MCAwIDAgc2V0cmdiY29sb3J9IGRlZgoKL3NvbGlkIHsgfSBiaW5kIGRlZgov ZG90dGVkIHsgWzEgMl0gMSBzZXRkYXNofSBiaW5kIGRlZgovZGFzaGVkIHsg WzQgOF0gMCBzZXRkYXNofSBiaW5kIGRlZgoKL3JlY3RhbmdsZSAlIE9yaWdp blggT3JpZ2luWSBXaWR0aCBIZWlnaHQKeyBuZXdwYXRoCiAgMyBpbmRleCAz IGluZGV4IG1vdmV0byAlIE9yaWdpblgvT3JpZ2luWQogIDEgaW5kZXggMCBy bGluZXRvICUgT3JpZ2luWCtXaWR0aC9PcmlnaW5ZCiAgMCAxIGluZGV4IG5l ZyBybGluZXRvICUgT3JpZ2luWCtXaWR0aC9PcmlnaW5ZK0hlaWdodAogIGV4 Y2ggbmVnIDAgcmxpbmV0byAlIE9yaWdpblgvT3JpZ2luWStIZWlnaHQKICAw IGV4Y2ggcmxpbmV0byAlIE9yaWdpblgvT3JpZ2luWQogIGNsb3NlcGF0aCBw b3AgcG9wCn0gZGVmCi9kcmF3X3JlY3RhbmdsZSB7IGdzYXZlIHJlY3Rhbmds ZSBzdHJva2UgZ3Jlc3RvcmV9IGRlZgovZmlsbF9yZWN0YW5nbGUgeyBnc2F2 ZSByZWN0YW5nbGUgZmlsbCBncmVzdG9yZX0gZGVmCgovY2lyY2xlICUgT3Jp Z2luWCBPcmlnaW5ZIDIqUmFkaXVzCnsgbmV3cGF0aAogIDIgaW5kZXggMSBp bmRleCAyIGRpdiBhZGQgMiBpbmRleCAyIGluZGV4IDIgZGl2IHN1YiAlIENl bnRlclgvQ2VudGVyWQogIDIgaW5kZXggMiBkaXYgMCAzNjAgYXJjCiAgY2xv c2VwYXRoIHBvcCBwb3AgcG9wCn0gZGVmCi9kcmF3X2NpcmNsZSB7IGdzYXZl IGNpcmNsZSBzdHJva2UgZ3Jlc3RvcmV9IGRlZgovZmlsbF9jaXJjbGUgeyBn c2F2ZSBjaXJjbGUgZmlsbCBncmVzdG9yZX0gZGVmCgovZWxsaXBzZSAlIE9y aWdpblggT3JpZ2luWSBXaWR0aCBIZWlnaHQKeyBuZXdwYXRoCiAgMyBpbmRl eCAzIGluZGV4IDIgaW5kZXggMC41IG11bCBzdWIgbW92ZXRvICUgT3JpZ2lu WC9PcmlnaW5ZLShIZWlnaHQvMikKICAzIGluZGV4IDMgaW5kZXggMiBpbmRl eCAwLjE0IG11bCBhZGQgJSBPcmlnaW5YL09yaWdpblkrKEhlaWdodCowLjE0 KQogIDUgaW5kZXggNCBpbmRleCBhZGQgNSBpbmRleCA0IGluZGV4IDAuMTQg bXVsIGFkZCAlIE9yaWdpblgrV2lkdGgvT3JpZ2luWSsoSGVpZ2h0KjAuMTQp CiAgNyBpbmRleCA2IGluZGV4IGFkZCA3IGluZGV4IDYgaW5kZXggMC41IG11 bCBzdWIgY3VydmV0byAlIE9yaWdpblgrV2lkdGgvT3JpZ2luWS0oSGVpZ2h0 LzIpCiAgMyBpbmRleCAyIGluZGV4IGFkZCAzIGluZGV4IDIgaW5kZXggMS4x NCBtdWwgc3ViICUgT3JpZ2luWCtXaWR0aC9PcmlnaW5ZLShIZWlnaHQqMS4x NCkKICA1IGluZGV4IDUgaW5kZXggNCBpbmRleCAxLjE0IG11bCBzdWIgJSBP cmlnaW5YL09yaWdpblktKEhlaWdodCoxLjE0KQogIDcgaW5kZXggNyBpbmRl eCA2IGluZGV4IDAuNSBtdWwgc3ViIGN1cnZldG8gJSBPcmlnaW5YL09yaWdp blktKEhlaWdodC8yKQogIGNsb3NlcGF0aCBwb3AgcG9wIHBvcCBwb3AKfSBk ZWYKL2RyYXdfZWxsaXBzZSB7Z3NhdmUgZWxsaXBzZSBzdHJva2UgZ3Jlc3Rv cmV9IGRlZgovZmlsbF9lbGxpcHNlIHtnc2F2ZSBlbGxpcHNlIGZpbGwgZ3Jl c3RvcmV9IGRlZgoKL3Job21idXMgJSBPcmlnaW5YIE9yaWdpblkgV2lkdGgg SGVpZ2h0CnsgbmV3cGF0aAogIDMgaW5kZXggMiBpbmRleCAyIGRpdiBhZGQg MyBpbmRleCBtb3ZldG8gJSBPcmlnaW5YKyhXaWR0aC8yKS9PcmlnaW5ZCiAg MSBpbmRleCAyIGRpdiAxIGluZGV4IDIgZGl2IG5lZyBybGluZXRvICUgT3Jp Z2luWCtXaWR0aC9PcmlnaW5ZLShIZWlnaHQvMikKICAxIGluZGV4IDIgZGl2 IG5lZyAxIGluZGV4IDIgZGl2IG5lZyBybGluZXRvICUgT3JpZ2luWCsoV2lk dGgvMikvT3JpZ2luWS1IZWlnaHQKICAxIGluZGV4IDIgZGl2IG5lZyAxIGlu ZGV4IDIgZGl2IHJsaW5ldG8gJSBPcmlnaW5YL09yaWdpblktKEhlaWdodC8y KQogIGNsb3NlcGF0aCBwb3AgcG9wIHBvcCBwb3AKfSBkZWYKL2RyYXdfcmhv bWJ1cyB7Z3NhdmUgcmhvbWJ1cyBzdHJva2UgZ3Jlc3RvcmV9IGRlZgovZmls bF9yaG9tYnVzIHtnc2F2ZSByaG9tYnVzIGZpbGwgZ3Jlc3RvcmV9IGRlZgoK L3RyaWFuZ2xlICUgT3JpZ2luWCBPcmlnaW5ZIFdpZHRoIEhlaWdodAp7IG5l d3BhdGgKICAzIGluZGV4IDIgaW5kZXggMiBkaXYgYWRkIDMgaW5kZXggbW92 ZXRvICUgT3JpZ2luWCsoV2lkdGgvMikvT3JpZ2luWQogIDEgaW5kZXggMiBk aXYgMSBpbmRleCBuZWcgcmxpbmV0byAlIE9yaWdpblgrV2lkdGgvT3JpZ2lu WS1IZWlnaHQKICAxIGluZGV4IG5lZyAwIHJsaW5ldG8gJSBPcmlnaW5YL09y aWdpblktSGVpZ2h0CiAgY2xvc2VwYXRoIHBvcCBwb3AgcG9wIHBvcAp9IGRl ZgovZHJhd190cmlhbmdsZSB7Z3NhdmUgdHJpYW5nbGUgc3Ryb2tlIGdyZXN0 b3JlfSBkZWYKL2ZpbGxfdHJpYW5nbGUge2dzYXZlIHRyaWFuZ2xlIGZpbGwg Z3Jlc3RvcmV9IGRlZgoKL2RyYXdfc3RyaW5nICUgU3RyaW5nIENlbnRlclgg Q2VudGVyWQp7IGdzYXZlIG1vdmV0byBzaG93IGdyZXN0b3JlCn0gZGVmCgov ZHJhd19jZW50ZXJlZF9zdHJpbmcgJSBTdHJpbmcgQ2VudGVyWCBDZW50ZXJZ CnsgZ3NhdmUgbmV3cGF0aCAKCWV4Y2ggMiBpbmRleCBzdHJpbmd3aWR0aCBw b3AgMiBkaXYgc3ViIGV4Y2ggCgltb3ZldG8gc2hvdyBncmVzdG9yZQp9IGRl ZgoKL2RyYXdfbGluZSAlIFN0YXJ0WCBTdGFydFkgRW5kWCBFbmRYCnsgZ3Nh dmUgbmV3cGF0aCAzIGluZGV4IDMgaW5kZXggbW92ZXRvIGxpbmV0byBjbG9z ZXBhdGggcG9wIHBvcCAKCXN0cm9rZSBncmVzdG9yZQp9IGRlZgoKL2RyYXdf YXJyb3cgJSBIZWFkWCBIZWFkWSBQb2ludDFYIFBvaW50MVkgUG9pbnQyWCBQ b2ludDJZCnsgZ3NhdmUgbmV3cGF0aCBtb3ZldG8gbGluZXRvIGxpbmV0byBj bG9zZXBhdGggc3Ryb2tlIGdyZXN0b3JlfSBkZWYKCi9maWxsX2Fycm93ICUg SGVhZFggSGVhZFkgUG9pbnQxWCBQb2ludDFZIFBvaW50MlggUG9pbnQyWQp7 IGdzYXZlIG5ld3BhdGggbW92ZXRvIGxpbmV0byBsaW5ldG8gY2xvc2VwYXRo IGZpbGwgZ3Jlc3RvcmV9IGRlZgoKL2RyYXdfc2VsZnJlZl9jaXJjbGUgJSBP cmlnaW5YIE9yaWdpblkgMipSYWRpdXMKeyBnc2F2ZSBuZXdwYXRoCiAgMiBp bmRleCAxIGluZGV4IDIgZGl2IGFkZCAyIGluZGV4IDIgaW5kZXggMiBkaXYg c3ViICUgQ2VudGVyWC9DZW50ZXJZCiAgMiBpbmRleCAyIGRpdiA0NSAzNjAg YXJjCiAgcG9wIHBvcCBwb3Agc3Ryb2tlIGdyZXN0b3JlCn0gZGVmCgovZHJh d19zZWxmcmVmX2NpcmNsZV9ob3Jpem9udGFsICUgT3JpZ2luWCBPcmlnaW5Z IDIqUmFkaXVzCnsgZ3NhdmUgbmV3cGF0aAogIDIgaW5kZXggMSBpbmRleCAy IGRpdiBhZGQgMiBpbmRleCAyIGluZGV4IDIgZGl2IHN1YiAlIENlbnRlclgv Q2VudGVyWQogIDIgaW5kZXggMiBkaXYgMTM1IDQ1MCBhcmMKICBwb3AgcG9w IHBvcCBzdHJva2UgZ3Jlc3RvcmUKfSBkZWYKCi9yZWFkc3RyaW5nIHsKICBj dXJyZW50ZmlsZSBleGNoIHJlYWRoZXhzdHJpbmcgcG9wICAKfSBiaW5kIGRl ZgovcGljc3RyIDEgc3RyaW5nIGRlZgoKL2RhVmluY2lfbG9nbwp7IC9aYXBm Q2hhbmNlcnktTWVkaXVtSXRhbGljIGZpbmRmb250IDEwIHNjYWxlZm9udCBz ZXRmb250CiAgKGRhVmluY2kpIHNob3cKICA0IDAgcm1vdmV0byAvSGVsdmV0 aWNhIGZpbmRmb250IDggc2NhbGVmb250IHNldGZvbnQgKFYyLjEpIHNob3d9 IGRlZgoKJSVFbmRQcm9sb2cKCiUlQmVnaW5TZXR1cAolJUluY2x1ZGVSZXNv dXJjZToKJSUrIGZvbnQgTHVjaWRhU2FucwolJSsgZm9udCBMdWNpZGFTYW5z LUJvbGQKJSUrIGZvbnQgTHVjaWRhU2Fucy1JdGFsaWMKJSUrIGZvbnQgTHVj aWRhU2Fucy1Cb2xkSXRhbGljCiUlKyBmb250IFRpbWVzLVJvbWFuCiUlKyBm b250IFRpbWVzLUJvbGQKJSUrIGZvbnQgVGltZXMtSXRhbGljCiUlKyBmb250 IFRpbWVzLUJvbGRJdGFsaWMKJSUrIGZvbnQgSGVsdmV0aWNhCiUlKyBmb250 IEhlbHZldGljYS1Cb2xkCiUlKyBmb250IEhlbHZldGljYS1PYmxpcXVlCiUl KyBmb250IEhlbHZldGljYS1Cb2xkT2JsaXF1ZQolJSsgZm9udCBIZWx2ZXRp Y2EtTmFycm93CiUlKyBmb250IEhlbHZldGljYS1OYXJyb3ctQm9sZAolJSsg Zm9udCBIZWx2ZXRpY2EtTmFycm93LU9ibGlxdWUKJSUrIGZvbnQgSGVsdmV0 aWNhLU5hcnJvdy1Cb2xkT2JsaXF1ZQolJSsgZm9udCBDb3VyaWVyCiUlKyBm b250IENvdXJpZXItQm9sZAolJSsgZm9udCBDb3VyaWVyLU9ibGlxdWUKJSUr IGZvbnQgQ291cmllci1Cb2xkT2JsaXF1ZQolJSsgZm9udCBaYXBmQ2hhbmNl cnktTWVkaXVtSXRhbGljCiUlRW5kU2V0dXAKCiUlUGFnZTogMSAxCgpnc2F2 ZSAyMCAxNSBtb3ZldG8gOTAgcm90YXRlIGRhVmluY2lfbG9nbyBncmVzdG9y ZQoyNSBkdXAgdHJhbnNsYXRlCjEuMDAwMCBkdXAgc2NhbGUKCmdzYXZlIDEg c2V0bGluZXdpZHRoCiAwLjAwIDAuMDAgMC4wMCBzZXRyZ2Jjb2xvciAgMTAz IDMyNiAxMDEgMzMzIDEwNSAzMzMgZmlsbF9hcnJvdyAxIHNldGxpbmV3aWR0 aAoxMDMgMzc0IDEwMyAzMzMgZHJhd19saW5lCjEgc2V0bGluZXdpZHRoIGdy ZXN0b3JlCgpmb250X2x1Y2lkYV9ib2xkCiAwLjU2IDAuOTMgMC41NiBzZXRy Z2Jjb2xvciAgNjUgMzk4IDc2IDI0IGZpbGxfcmVjdGFuZ2xlCmJsYWNrIDY1 IDM5OCA3NiAyNCBkcmF3X3JlY3RhbmdsZQooMDogRU5UUllfT1VUR09JTkcp IDY3IDM5MSBkcmF3X3N0cmluZwooaW4gID0gMCEpIDY3IDM4NCBkcmF3X3N0 cmluZwoob3V0ID0gMSEpIDY3IDM3NyBkcmF3X3N0cmluZwpnc2F2ZSAxIHNl dGxpbmV3aWR0aAogMC4wMCAwLjAwIDAuMDAgc2V0cmdiY29sb3IgIDE0OCAy NTQgMTQyIDI1OCAxNDYgMjYxIGZpbGxfYXJyb3cgMSBzZXRsaW5ld2lkdGgK MTExIDMwMiAxNDQgMjU5IGRyYXdfbGluZQoxIHNldGxpbmV3aWR0aCBncmVz dG9yZQpnc2F2ZSAxIHNldGxpbmV3aWR0aAogMC4wMCAwLjAwIDAuMDAgc2V0 cmdiY29sb3IgIDU5IDI1NCA2MSAyNjEgNjUgMjU4IGZpbGxfYXJyb3cgMSBz ZXRsaW5ld2lkdGgKOTUgMzAyIDYzIDI1OSBkcmF3X2xpbmUKMSBzZXRsaW5l d2lkdGggZ3Jlc3RvcmUKCmZvbnRfbHVjaWRhX2JvbGQKIDEuMDAgMS4wMCAx LjAwIHNldHJnYmNvbG9yICA4MCAzMjYgNDcgMjQgZmlsbF9yZWN0YW5nbGUK YmxhY2sgODAgMzI2IDQ3IDI0IGRyYXdfcmVjdGFuZ2xlCigxOiBJTkNPTUlO RykgODIgMzE5IGRyYXdfc3RyaW5nCihpbiAgPSAxISkgODIgMzEyIGRyYXdf c3RyaW5nCihvdXQgPSAxISkgODIgMzA1IGRyYXdfc3RyaW5nCmdzYXZlIDEg c2V0bGluZXdpZHRoCiAwLjAwIDAuMDAgMC4wMCBzZXRyZ2Jjb2xvciAgNTEg MTgyIDQ5IDE4OSA1MyAxODkgZmlsbF9hcnJvdyAxIHNldGxpbmV3aWR0aAo1 MSAyMzAgNTEgMTg5IGRyYXdfbGluZQoxIHNldGxpbmV3aWR0aCBncmVzdG9y ZQoKZm9udF9sdWNpZGFfYm9sZAogMS4wMCAxLjAwIDEuMDAgc2V0cmdiY29s b3IgIDE3IDI1NCA2OCAyNCBmaWxsX3JlY3RhbmdsZQpibGFjayAxNyAyNTQg NjggMjQgZHJhd19yZWN0YW5nbGUKKDI6IEJSQU5DSF9UQUtFTikgMTkgMjQ3 IGRyYXdfc3RyaW5nCihpbiAgPSAxISkgMTkgMjQwIGRyYXdfc3RyaW5nCihv dXQgPSAxISkgMTkgMjMzIGRyYXdfc3RyaW5nCmdzYXZlIDEgc2V0bGluZXdp ZHRoCiAwLjAwIDAuMDAgMC4wMCBzZXRyZ2Jjb2xvciAgMTUzIDE4MiAxNTEg MTg5IDE1NSAxODggZmlsbF9hcnJvdyAxIHNldGxpbmV3aWR0aAoxNTYgMjMw IDE1MyAxODggZHJhd19saW5lCjEgc2V0bGluZXdpZHRoIGdyZXN0b3JlCgpm b250X2x1Y2lkYV9ib2xkCiAxLjAwIDEuMDAgMS4wMCBzZXRyZ2Jjb2xvciAg MTEzIDI1NCA4NiAyNCBmaWxsX3JlY3RhbmdsZQpibGFjayAxMTMgMjU0IDg2 IDI0IGRyYXdfcmVjdGFuZ2xlCigzOiBCUkFOQ0hfTk9UX1RBS0VOKSAxMTUg MjQ3IGRyYXdfc3RyaW5nCihpbiAgPSAwISkgMTE1IDI0MCBkcmF3X3N0cmlu Zwoob3V0ID0gMCEpIDExNSAyMzMgZHJhd19zdHJpbmcKZ3NhdmUgMSBzZXRs aW5ld2lkdGgKIDAuMDAgMC4wMCAwLjAwIHNldHJnYmNvbG9yICA5NCAxMTAg ODggMTE0IDkyIDExNyBmaWxsX2Fycm93IDEgc2V0bGluZXdpZHRoCjU5IDE1 OCA5MCAxMTUgZHJhd19saW5lCjEgc2V0bGluZXdpZHRoIGdyZXN0b3JlCgpm b250X2x1Y2lkYV9ib2xkCiAxLjAwIDEuMDAgMS4wMCBzZXRyZ2Jjb2xvciAg MTQgMTgyIDc0IDI0IGZpbGxfcmVjdGFuZ2xlCmJsYWNrIDE0IDE4MiA3NCAy NCBkcmF3X3JlY3RhbmdsZQooNDogQ0FMTF9JTk9VVFNBTUUpIDE2IDE3NSBk cmF3X3N0cmluZwooaW4gID0gMSEpIDE2IDE2OCBkcmF3X3N0cmluZwoob3V0 ID0gMSEpIDE2IDE2MSBkcmF3X3N0cmluZwpnc2F2ZSAxIHNldGxpbmV3aWR0 aAogMC4wMCAwLjAwIDAuMDAgc2V0cmdiY29sb3IgIDExMCAxMTAgMTEyIDEx NyAxMTYgMTE0IGZpbGxfYXJyb3cgMSBzZXRsaW5ld2lkdGgKMTQ1IDE1OCAx MTQgMTE1IGRyYXdfbGluZQoxIHNldGxpbmV3aWR0aCBncmVzdG9yZQoKZm9u dF9sdWNpZGFfYm9sZAogMS4wMCAxLjAwIDEuMDAgc2V0cmdiY29sb3IgIDEx NiAxODIgNzQgMjQgZmlsbF9yZWN0YW5nbGUKYmxhY2sgMTE2IDE4MiA3NCAy NCBkcmF3X3JlY3RhbmdsZQooNTogQ0FMTF9JTk9VVFNBTUUpIDExOCAxNzUg ZHJhd19zdHJpbmcKKGluICA9IDAhKSAxMTggMTY4IGRyYXdfc3RyaW5nCihv dXQgPSAwISkgMTE4IDE2MSBkcmF3X3N0cmluZwpnc2F2ZSAxIHNldGxpbmV3 aWR0aAogMC4wMCAwLjAwIDAuMDAgc2V0cmdiY29sb3IgIDEwMiAzOCAxMDAg NDUgMTA0IDQ1IGZpbGxfYXJyb3cgMSBzZXRsaW5ld2lkdGgKMTAyIDg2IDEw MiA0NSBkcmF3X2xpbmUKMSBzZXRsaW5ld2lkdGggZ3Jlc3RvcmUKCmZvbnRf bHVjaWRhX2JvbGQKIDEuMDAgMS4wMCAxLjAwIHNldHJnYmNvbG9yICA4NCAx MTAgMzYgMjQgZmlsbF9yZWN0YW5nbGUKYmxhY2sgODQgMTEwIDM2IDI0IGRy YXdfcmVjdGFuZ2xlCig2OiAtLS0tLS0pIDg2IDEwMyBkcmF3X3N0cmluZwoo aW4gID0gMSEpIDg2IDk2IGRyYXdfc3RyaW5nCihvdXQgPSAxISkgODYgODkg ZHJhd19zdHJpbmcKCmZvbnRfbHVjaWRhX2JvbGQKIDAuNTYgMC45MyAwLjU2 IHNldHJnYmNvbG9yICA3OSAzOCA0NyAyNCBmaWxsX3JlY3RhbmdsZQpibGFj ayA3OSAzOCA0NyAyNCBkcmF3X3JlY3RhbmdsZQooNzogSU5DT01JTkcpIDgx IDMxIGRyYXdfc3RyaW5nCihpbiAgPSAxISkgODEgMjQgZHJhd19zdHJpbmcK KG91dCA9IDAhKSA4MSAxNyBkcmF3X3N0cmluZwoKZW5kCnNob3dwYWdlCiUl VHJhaWxlcgolJUVPRgo= ---2138965737-1998950407-991971410=:24742 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="test.c" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: a simple c program Content-Disposition: ATTACHMENT; FILENAME="test.c" bWFpbigpDQp7DQoJaWYoMSkNCgkJcHJpbnRmKCIxXG4iKTsNCgllbHNlDQoJ CXByaW50ZigiMFxuIik7DQoJCQ0KCXJldHVybjsNCn0NCg== ---2138965737-1998950407-991971410=:24742-- From owner-pro64-support@linux-xfs.sgi.com Sat Jun 9 01:40:12 2001 Received: (from mail@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f598eCAp007974 for pro64-support-outgoing; Sat, 9 Jun 2001 01:40:12 -0700 X-Authentication-Warning: linux-xfs.sgi.com: mail set sender to owner-pro64-support@oss.sgi.com using -f Received: from mail.ict.ac.cn ([159.226.39.4]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f598e73D007961 for ; Sat, 9 Jun 2001 01:40:07 -0700 Received: (qmail 21256 invoked from network); 9 Jun 2001 08:35:02 -0000 Received: from unknown (HELO zsk) (@159.226.40.246) by 159.226.39.4 with SMTP; 9 Jun 2001 08:35:02 -0000 Message-ID: <008d01c0f0c0$30240d30$280379c8@zsk> From: "Shukang ZHOU" To: "sgi" References: Subject: Re: CFG by daVinci (fwd) Date: Sat, 9 Jun 2001 16:42:56 +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 I have scrutinized the whole Pro64 source code and I think I have found the routine to display your picture. (be/com/fb_cfg.cxx Line 1911) void dV_view_fb_cfg( const FB_CFG& cfg, WN *root_wn, const char *caller ) In fact, the content of graph is handled by void FB_CFG::Draw() const (be/com/fb_cfg.cxx Line 1866) And the node label is handled by char * FB_CFG::Node_label( FB_NODEX nx ) const (be/com/fb_cfg.cxx Line 1819) To my best understanding, each block in the graph represents for a FB_NODE. And the content in the block are ID, node_type, incoming frequency, and outgoing frequency. "-------" is the node_type, standing for that FB_NODE node_type is FB_EDGE_UNINT (0). Maybe your graph is not a CLASSIC cfg, in which a node should be a basic block. So there are more blocks than your expectation. And the number in block starting from 0 can be also understood this way. What's your opinion? Shukang, ZHOU Dept. of Computer Science & Technology Peking University E-mail: zhshk@ict.ac.cn zhoushukang@yahoo.com ----- Original Message ----- From: "Peng Zhao" To: "sgi" Sent: Saturday, June 09, 2001 5:35 AM Subject: CFG by daVinci (fwd) > > > Hi, > > I have a question about the CFG drew by daVinci. > > Enclosed are two files, one is a very simple c program and the > other one is the corresponding CFG just after annotation. It is a little > strange for me. > > First, block 2 and 4 should be one (basic block) and 3&5 too. Why > draw them two separated blocks. > > What is the meaning of block 6 ( especially: the meanning of > "-----")? Does it mean the "return" statement in the program? > > What does the block 7 stand for? > > BTW1: what is the relationship between the ID of each block in > the CFG drew by daVinci and the corresponding BB_NODE->Id()? > > BTW2: What is COMMA, RCOMMA, MU and CHI? > > > 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 Sun Jun 10 15:29:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5AMTom09843 for pro64-support-outgoing; Sun, 10 Jun 2001 15:29:50 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5AMTlV09833 for ; Sun, 10 Jun 2001 15:29:47 -0700 Received: from dsl-proof.corp.sgi.com (dsl-proof.corp.sgi.com [192.102.142.250]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA00301 for ; Sun, 10 Jun 2001 15:30:05 -0700 (PDT) mail_from (dlstephe@sgi.com) Received: from sgi.com (localhost [127.0.0.1]) by dsl-proof.corp.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id PAA25758; Sun, 10 Jun 2001 15:33:45 -0700 (PDT) Message-ID: <3B23F5C8.8DD4610C@sgi.com> Date: Sun, 10 Jun 2001 15:33:44 -0700 From: David Stephenson Organization: SGI -- Compilers X-Mailer: Mozilla 4.76C-SGI [en] (X11; I; IRIX 6.5 IP32) X-Accept-Language: en MIME-Version: 1.0 To: Shukang ZHOU , sgi , Peng Zhao Subject: Re: CFG by daVinci (fwd) References: <008d01c0f0c0$30240d30$280379c8@zsk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Feedback frequencies as stored in memory using three different formats, for different phases of the compiler. WOPT and CG each have their own control flow graph structures, which are annotated with the frequency data. Within the other compiler phases, no CFG is maintained; the WHIRL representation does not come with a build in CFG. Periodically, frequencies that annotate the WHIRL code are updated by propagation. Where possible, unknown frequencies are replaced by known frequencies, and GUESS frequencies are replaced by EXACT frequencies. This propagation requires a CFG, but WHIRL has no CFG, so a temporary CFG (the class FB_CFG) is constructed from the WHIRL code just while propagating frequencies. FB_CFG has some unique features, so it doesn't quite correspond to any of the CFGs used within WOPT or CG. In general, each frequency value in the annotated WHIRL has one block associated with in. In Peng Zhao's example, the "if" WHIRL node has two frequency values assigned to it: a count of the number of times that the branch was taken during the execution of the instrumented binary, and a count of the number of times that the branch was not taken. A CALL node may be associated with either one or two frequency counts (depending on whether it is known that the CALL always returned). Block 0 Function entry Block 1 PRAGMA Block 2 IF (taken) Block 3 IF (not taken) Block 4 CALL printf Block 5 CALL printf Block 6 Block 7 RETURN The merge block 6 doesn't correspond to any particular WHIRL node, but is required to complete the graph. In the graph displayed by daVinci, the block numbers only correspond to the block numbers within FB_CFG. The labels indicate the total incoming and outgoing frequencies for each node. Green blocks indicate that the incoming and outgoing frequencies differ. Red blocks indicate uninitialized or The color of the blocks help detect errors by highlighting blocks where the frequencies are uninitialized or don't agree with neighboring blocks. Peng Zhao wrote: > I have a question about the CFG drew by daVinci. > > Enclosed are two files, one is a very simple c program and the > other one is the corresponding CFG just after annotation. It is > a little strange for me. Shukang ZHOU wrote: > To my best understanding, each block in the graph represents for a FB_NODE. > And the content in the block are ID, node_type, incoming frequency, and > outgoing frequency. "-------" is the node_type, standing for that FB_NODE > node_type is FB_EDGE_UNINT (0). > > Maybe your graph is not a CLASSIC cfg, in which a node should be a basic > block. So there are more blocks than your expectation. And the number in > block starting from 0 can be also understood this way. Exactly right. Peng Zhao wrote: > First, block 2 and 4 should be one (basic block) and 3&5 too. Why > draw them two separated blocks. They correspond to two different frequency values, for two different WHIRL nodes. Blocks 2 and 3 correspond to the IF node, while blocks 4 and 5 each correspond to one of the printf CALL nodes. > What is the meaning of block 6 ( especially: the meanning of > "-----")? Does it mean the "return" statement in the program? > > What does the block 7 stand for? Block 7 corresponds to the return statement. Block 6 is a merge block that doesn't correspond to any WHIRL node, so "-----" means "none". > BTW1: what is the relationship between the ID of each block in > the CFG drew by daVinci and the corresponding BB_NODE->Id()? Not much. The class BB_NODE is part of the WOPT CFG structure, but the graph drawn by daVinci is from the FB_CFG structure, used outside of WOPT AND CG. > BTW2: What is COMMA, RCOMMA, MU and CHI? COMMA and RCOMMA are WHIRL operators described in the WHIRL reference document whirl.pdf available at http://oss.sgi.com/projects/Pro64/download.html MU and CHI nodes are annotations to the Single Static Assignment (SSA) form within WOPT used to represent aliasing info. For more information, check out the research paper Fred C. Chow, Sun Chan, Shin-Ming Liu, Raymond Lo, and Mark Streich. Effective Representation of Aliases and Indirect Memory Operations in SSA Form. In Proceedings of the Sixth International Conference on Compiler Construction, Lecture Notes in Computer Science, Vol.1060, pages 253-267, Springer, April 1996. available at: http://citeseer.nj.nec.com/395004.html - David -- David Stephenson http://reality.sgi.com/dlstephe_engr/ From owner-pro64-support@oss.sgi.com Mon Jun 11 15:08:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5BM8TC22123 for pro64-support-outgoing; Mon, 11 Jun 2001 15:08:29 -0700 Received: from inet-mail4.oracle.com (inet-mail4.oracle.com [148.87.2.204]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5BM8TV22120 for ; Mon, 11 Jun 2001 15:08:29 -0700 Received: from gmgw01.us.oracle.com (gmgw01.us.oracle.com [130.35.249.115]) by inet-mail4.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5BM3Df11805 for ; Mon, 11 Jun 2001 15:03:14 -0700 (PDT) Received: from oracle.com (dhcp-4ip3-4ip4-west-130-35-146-116.us.oracle.com [130.35.146.116]) by gmgw01.us.oracle.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f5BM8NX01142 for ; Mon, 11 Jun 2001 15:08:23 -0700 (PDT) Message-ID: <3B254165.D4A6636C@oracle.com> Date: Mon, 11 Jun 2001 15:08:37 -0700 From: Ken Chen X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.4.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: pro64-support@oss.sgi.com Subject: compiler switch to build ia64 kernel Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pro64-support@oss.sgi.com Precedence: bulk I am following the FAQ on sgi's web site for building Linux/IA-64 kernel with sgi pro64 compiler. But it appears that it either doesn't compile or doesn't link. Does anyone has tried to compile linux-2.4.2 kernel with "SGIcc Compilers: Version 0.01.0-13"? These switches will not compile arch/ia64/kernel/acpi.c and other files. CROSS_COMPILE = CC = sgicc -D__KERNEL__ -I$(HPATH) -D__LP64__ CFLAGS = $(CPPFLAGS) -Wall -Wstrict-prototypes -O0 -fomit-frame-pointer -ffixed-r15 -CG:emit_unwind_info=off -Wf,-O2 -PHASE:p -D__OPTIMIZE -OPT:Olimit=5000 From owner-pro64-support@oss.sgi.com Mon Jun 11 20:17:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5C3HFI26931 for pro64-support-outgoing; Mon, 11 Jun 2001 20:17:15 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5C3HEV26927 for ; Mon, 11 Jun 2001 20:17:14 -0700 Received: from rohi.engr.sgi.com (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 UAA08373 for ; Mon, 11 Jun 2001 20:17:11 -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 UAA45647; Mon, 11 Jun 2001 20:13:01 -0700 (PDT) Date: Mon, 11 Jun 2001 20:13:01 -0700 (PDT) From: mpm@rohi.engr.sgi.com (Michael Murphy) Message-Id: <200106120313.UAA45647@rohi.engr.sgi.com> To: pro64-support@oss.sgi.com, Ken Chen Subject: Re: compiler switch to build ia64 kernel Sender: owner-pro64-support@oss.sgi.com Precedence: bulk We have not tried to build the kernel in a long time (and the last time we tried, it didn't work). It was dropped as a priority since the kernel developers wanted to stick with gcc. -- Mike Murphy -- mpm@sgi.com -- quote of the day: -- Two stonecutters were cutting stones into blocks. -- The first said, "I'm cutting stones into blocks", -- the second said, "I'm on a team that is building a cathedral." From owner-pro64-support@oss.sgi.com Tue Jun 12 00:47:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5C7l7R14342 for pro64-support-outgoing; Tue, 12 Jun 2001 00:47:07 -0700 Received: from roura.ac.upc.es ([147.83.33.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5C7l4V14338 for ; Tue, 12 Jun 2001 00:47:04 -0700 Received: from ac.upc.es (goday.ac.upc.es [147.83.32.5]) by roura.ac.upc.es (8.11.0/8.11.0) with ESMTP id f5C7klN20644 for ; Tue, 12 Jun 2001 09:46:47 +0200 (MET DST) Message-ID: <3B25C8E6.EE23FA04@ac.upc.es> Date: Tue, 12 Jun 2001 09:46:46 +0200 From: Eduard Santamaria Organization: DAC-UPC X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.7 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: pro64-support@oss.sgi.com Subject: problems with gcc benchmark Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Hi, I'm testing the Pro64 with the SPEC95 benchmarks on an IA-32 Linux box with NUE. I've been able to compile and run all of them except gcc, which I can compile but crashes when put to run. Has anyone had the same problem? How should I compile to achieve successful execution? bash$ uname -a Linux fontsere 2.4.2-2 #1 Sun Apr 8 20:41:30 EDT 2001 ia64 unknown bash$ sgif90 -v SGIcc Compilers: Version 0.01.0-12 I've also detected minor differences between the output generated by mgrid and the reference output (test) of the benchmark, both within the NUE environment and on a real IA-64. I've checked the compiler options related to IEEE-754. Although the results are acceptable, perhaps somebody will be able to explain why this differences occur. Thanks, Eduard. -- _____________________________________________________________________ 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 Tue Jun 12 14:12:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5CLCZK02517 for pro64-support-outgoing; Tue, 12 Jun 2001 14:12:35 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5CLCXP02509 for ; Tue, 12 Jun 2001 14:12:34 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [144.253.131.5]) 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 OAA02630 for ; Tue, 12 Jun 2001 14:00:12 -0700 (PDT) mail_from (mpm@rohi.engr.sgi.com) 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 WAA58897 for ; Tue, 12 Jun 2001 22:57:37 +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 NAA47264; Tue, 12 Jun 2001 13:53:36 -0700 (PDT) Date: Tue, 12 Jun 2001 13:53:36 -0700 (PDT) From: mpm@rohi.engr.sgi.com (Michael Murphy) Message-Id: <200106122053.NAA47264@rohi.engr.sgi.com> To: pro64-support@oss.sgi.com, Eduard Santamaria Subject: Re: problems with gcc benchmark Sender: owner-pro64-support@oss.sgi.com Precedence: bulk We only tested spec on the real ia64 hardware, not under NUE, so there may be some NUE-related problem there. Also, we've been testing with spec2000 not spec95. -- Mike Murphy -- mpm@sgi.com -- quote of the day: -- "The three principle virtues of a programmer are -- Laziness, Impatience, and Hubris." -- Larry Wall From owner-pro64-support@oss.sgi.com Tue Jun 12 17:07:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5D07SO30751 for pro64-support-outgoing; Tue, 12 Jun 2001 17:07:28 -0700 Received: from sunkay.cs.ualberta.ca (root@sunkay.cs.ualberta.ca [129.128.4.11]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5D07LP30720; Tue, 12 Jun 2001 17:07:24 -0700 Received: (from localhost user: 'pengzhao' uid#483 fake: STDIN (pengzhao@peers)) by sunkay.cs.ualberta.ca id ; Tue, 12 Jun 2001 18:07:06 -0600 Date: Tue, 12 Jun 2001 18:07:06 -0600 (MDT) From: Peng Zhao To: sgi , pro64 Subject: OPT_FEEDBACK Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-2138965737-293530481-992390826=:31140" 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-293530481-992390826=:31140 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, Enclosed is my c program ( a inner product program). I use -O3 to activate the PREOPT_LNO_PHASE, but the OPT_FEEDBACK generated in the Pre_Optimizer() is a little strange. Essentially, it is the LOOP related edges (LOOP_ZERO, LOOP_OUT, LOOP_POSITIVE,LOOPBACK). To me, it is not a classic CFG either. Two edges from bb9 to bb13(LOOP_ZERO, LOOP_OUT) and two edges from bb9 to bb10(LOOP_POSITIVE,LOOPBACK). and the whole CFG has not a single EXIT block. Is this CFG valid? check the end of this message for details. The OPT_FEEDBACK generated in WOPT phase is a better one. but at that time, I cannot identify the backedges in the CFG directly (i.e. using previous analysis results, I had thought an edge should be marked as backedge, But the OPT_FB_EDGE->edge_type only holds OUTGOING,BR_NOT_TAKEN and BR_TAKEN). This makes the traversing of the CFG difficult for avoiding the backedge infinite loops. 13 nodes: Node[1]: in_out_same N, update_count 0 in: unknown 0, unexact 0, freq_total 0!, edges [ ], out: unknown 0, unexact 0, freq_total 1!, edges [ 1 ] Node[2]: in_out_same Y, update_count 0 in: unknown 0, unexact 0, freq_total 1!, edges [ 1 ], out: unknown 0, unexact 0, freq_total 1!, edges [ 2 3 ] Node[3]: in_out_same Y, update_count 0 in: unknown 0, unexact 0, freq_total 0!, edges [ 2 ], out: unknown 0, unexact 0, freq_total 0!, edges [ 4 ] Node[4]: in_out_same Y, update_count 0 in: unknown 0, unexact 0, freq_total 1!, edges [ 3 ], out: unknown 0, unexact 0, freq_total 1!, edges [ 5 ] Node[5]: in_out_same Y, update_count 0 in: unknown 0, unexact 0, freq_total 1!, edges [ 4 5 ], out: unknown 0, unexact 0, freq_total 1!, edges [ 6 7 ] Node[6]: in_out_same Y, update_count 0 in: unknown 0, unexact 0, freq_total 0!, edges [ 6 ], out: unknown 0, unexact 0, freq_total 0!, edges [ 8 ] Node[7]: in_out_same Y, update_count 0 in: unknown 0, unexact 0, freq_total 1!, edges [ 7 ], out: unknown 0, unexact 0, freq_total 1!, edges [ 9 ] Node[8]: in_out_same Y, update_count 0 in: unknown 0, unexact 0, freq_total 1!, edges [ 8 9 ], out: unknown 0, unexact 0, freq_total 1!, edges [ 10 ] Node[9]: in_out_same Y, update_count 0 in: unknown 0, unexact 0, freq_total 1001!, edges [ 10 17 ], out: unknown 0, unexact 0, freq_total 1001!, edges [ 11 12 13 14 ] Node[10]: in_out_same Y, update_count 0 in: unknown 0, unexact 0, freq_total 1000!, edges [ 13 14 ], out: unknown 0, unexact 0, freq_total 1000!, edges [ 15 ] Node[11]: in_out_same Y, update_count 0 in: unknown 0, unexact 0, freq_total 1000!, edges [ 15 ], out: unknown 0, unexact 0, freq_total 1000!, edges [ 16 ] Node[12]: in_out_same Y, update_count 0 in: unknown 0, unexact 0, freq_total 1000!, edges [ 16 ], out: unknown 0, unexact 0, freq_total 1000!, edges [ 17 ] Node[13]: in_out_same N, update_count 0 in: unknown 0, unexact 0, freq_total 1!, edges [ 11 12 ], out: unknown 0, unexact 0, freq_total 0!, edges [ ] 17 edges: Edge[ 1]: ( 1 --> 2) : freq = 1! : OUTGOING Edge[ 2]: ( 2 --> 3) : freq = 0! : BRANCH_NOT_TAKEN Edge[ 3]: ( 2 --> 4) : freq = 1! : BRANCH_TAKEN Edge[ 4]: ( 3 --> 5) : freq = 0! : OUTGOING Edge[ 5]: ( 4 --> 5) : freq = 1! :OUTGOING Edge[ 6]: ( 5 --> 6) : freq = 0! : BRANCH_NOT_TAKEN Edge[ 7]: ( 5 --> 7) : freq = 1! : BRANCH_TAKEN Edge[ 8]: ( 6 --> 8) : freq = 0! :OUTGOING Edge[ 9]: ( 7 --> 8) : freq = 1! : OUTGOING Edge[ 10]: ( 8 -->9) : freq = 1! : OUTGOING Edge[ 11]: ( 9 --> 13) : freq = 0! : LOOP_ZERO Edge[ 12]: ( 9 --> 13) : freq = 1! : LOOP_OUT Edge[ 13]: ( 9 --> 10) : freq = 1! : LOOP_POSITIVE Edge[ 14]: ( 9 --> 10) : freq = 999! :LOOP_BACK Edge[ 15]: ( 10 --> 11) : freq = 1000! : OUTGOING Edge[ 16]: ( 11 --> 12) : freq = 1000! : OUTGOING Edge[ 17]: ( 12 --> 9) : freq =1000! : OUTGOING ---2138965737-293530481-992390826=:31140 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="ip.c" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="ip.c" LyoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KKiAgaW5uZXItcHJvZCAg LS0tIGEgc2ltcGxlIGlubmVyIHByb2R1Y3QgbG9vcA0KKg0KKiAgQXV0aG9y OiBKb3NlIE5lbHNvbiBBbWFyYWwNCiogICAgICAgICAgRGVwYXJ0bWVudCBv ZiBDb21wdXRpbmcgU2NpZW5jZQ0KKiAgICAgICAgICBVbml2ZXJzaXR5IG9m IEFsYmVydGENCiogICAgICAgICAgaHR0cDovL3d3dy5jcy51YWxiZXJ0YS5j YS9+YW1hcmFsDQoqDQoqIFB1cnBvc2U6IEFuYWx5c2UgdGhlIGdlbmVyYXRp b24gb2Ygc29mdHdhcmUgcGlwZWxpbmVkIHNjaGVkdWxlcw0KKg0KKiBSZWxl YXNlIERhdGU6IEZlYnJ1YXJ5IDA4IDIwMDENCioNCioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKiovDQoNCg0KI2luY2x1ZGUgICA8c3RkaW8uaD4NCiNk ZWZpbmUgICAgTUFYX0xFTkdUSCAxMDAwMA0KDQpmbG9hdCBJbm5lclByb2R1 Y3QoZmxvYXQgKlggLGZsb2F0ICpaLCBpbnQgbGVuZ3RoKTsNCg0KbWFpbihp bnQgYXJnYywgY2hhciogYXJndltdKQ0Kew0KICBmbG9hdCBaW01BWF9MRU5H VEhdOw0KICBmbG9hdCBYW01BWF9MRU5HVEhdOw0KICBmbG9hdCBROw0KICBp bnQgIGxlbmd0aDsNCiAgaW50ICAgaTsNCg0KICBpZiAoYXJnYyAhPSAyKQ0K ICB7IGZwcmludGYoc3RkZXJyLCJzeW50YXg6IGlubmVyLXByb2QgPHZlY3Rv ciBsZW5naHQ+IFxuIik7DQogICAgZXhpdCgxKTsNCiAgfQ0KDQogIGxlbmd0 aCA9IGF0b2koYXJndlsxXSk7DQoNCiAgaWYobGVuZ3RoID4gTUFYX0xFTkdU SCkNCiAgICB7DQogICAgICBmcHJpbnRmKHN0ZGVyciwiU29ycnkgdmVjdG9y IGlzIHRvbyBsb25nLiBNdXN0IGJlIGxlc3MgdGhhbiAlZCBlbGVtZW50c1xu IixNQVhfTEVOR1RIKTsNCiAgICAgIGV4aXQoMSk7DQogICAgfQ0KDQogIGZv cihpPTAgOyBpPGxlbmd0aCA7IGkrKykNCiAgICB7DQogICAgICBYW2ldID0g KGZsb2F0KShpKzIpLzE1Ow0KICAgICAgWltpXSA9IChmbG9hdClpLShmbG9h dCkobGVuZ3RoKS8yLjA7DQogICAgfQ0KICBRID0gSW5uZXJQcm9kdWN0KFgs WixsZW5ndGgpOw0KICBwcmludGYoIklubmVyIFByb2R1Y3QgPSAlZlxuIixR KTsNCn0NCg0KZmxvYXQgSW5uZXJQcm9kdWN0KGZsb2F0ICpYICwgZmxvYXQg KlosIGludCBsZW5ndGgpDQp7DQogIGZsb2F0IFE7DQogIHVuc2lnbmVkIGlu dCBrOw0KDQogIFEgPSAwOw0KICBmb3Ioaz0wOyBrPCBsZW5ndGg7IGsrKykN CiAgICBRID0gUSArIFhba10qWltrXTsNCiAgcmV0dXJuIFE7DQp9DQo= ---2138965737-293530481-992390826=:31140-- From owner-pro64-support@oss.sgi.com Tue Jun 12 21:20:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5D4K4n02370 for pro64-support-outgoing; Tue, 12 Jun 2001 21:20:04 -0700 Received: from sunkay.cs.ualberta.ca (root@sunkay.cs.ualberta.ca [129.128.4.11]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5D4K2P02359 for ; Tue, 12 Jun 2001 21:20:03 -0700 Received: (from localhost user: 'pengzhao' uid#483 fake: STDIN (pengzhao@peers)) by sunkay.cs.ualberta.ca id ; Tue, 12 Jun 2001 22:19:51 -0600 Date: Tue, 12 Jun 2001 22:19:51 -0600 (MDT) From: Peng Zhao To: sgi Subject: what does SCF stands for? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Hi, #define LOWER_SCF (LOWER_DO_LOOP | LOWER_DO_WHILE | LOWER_WHILE_DO | LOWER_IF) Thanks. Peng From owner-pro64-support@oss.sgi.com Tue Jun 12 21:23:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5D4NN102840 for pro64-support-outgoing; Tue, 12 Jun 2001 21:23:23 -0700 Received: from mail-in.hq.tensilica.com (hq.tensilica.com [38.170.141.29]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5D4NNP02837 for ; Tue, 12 Jun 2001 21:23:23 -0700 Received: from tensilica.com (sarod.hq.tensilica.com [192.168.15.77]) by mail-in.hq.tensilica.com (8.9.3/8.9.3) with ESMTP id VAA16266; Tue, 12 Jun 2001 21:23:16 -0700 Message-ID: <3B26EBDD.ADB8EA4E@tensilica.com> Date: Tue, 12 Jun 2001 21:28:13 -0700 From: Ding-Kai Chen X-Mailer: Mozilla 4.75 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Peng Zhao CC: sgi Subject: Re: what does SCF stands for? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Structured Control Flow. Ding-Kai Peng Zhao wrote: > Hi, > > #define LOWER_SCF (LOWER_DO_LOOP | LOWER_DO_WHILE | LOWER_WHILE_DO | > LOWER_IF) > > Thanks. > > Peng From owner-pro64-support@oss.sgi.com Tue Jun 19 15:30:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5JMUj905095 for pro64-support-outgoing; Tue, 19 Jun 2001 15:30:45 -0700 Received: from kingcrab.informix.com (dns3.informix.com [192.147.112.7]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5JMUiV05092 for ; Tue, 19 Jun 2001 15:30:44 -0700 Received: from canary.informix.com (canary.mp.informix.com [158.58.14.12]) by kingcrab.informix.com (8.8.5/8.7.3) with ESMTP id PAA13058 for ; Tue, 19 Jun 2001 15:30:35 -0700 (PDT) Received: from xena.informix.com (xena.mp.informix.com [158.58.15.154]) by canary.informix.com (8.8.8+Sun/8.8.8) with ESMTP id PAA17247; Tue, 19 Jun 2001 15:30:35 -0700 (PDT) Received: by xena.informix.com (8.9.3+Sun/SMI-SVR4) id PAA06046; Tue, 19 Jun 2001 15:30:35 -0700 (PDT) From: rmenon@informix.com (Ram Menon) Message-Id: <200106192230.PAA06046@xena.informix.com> Subject: sgicc on linux ia64 To: pro64-support@oss.sgi.com Date: Tue, 19 Jun 2001 15:30:33 -0700 (PDT) Cc: rmenon@informix.com (Ram Menon) X-Mailer: ELM [version 2.5 PL5] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Hi, Is sgicc binaries available to download on Redhat linux running on Intel Itanium machines ?. I am seeing NUE binaries on SGI Website. thanks From owner-pro64-support@oss.sgi.com Tue Jun 19 17:49:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5K0nad25054 for pro64-support-outgoing; Tue, 19 Jun 2001 17:49:36 -0700 Received: from web11407.mail.yahoo.com (web11407.mail.yahoo.com [216.136.131.237]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5K0naV25050 for ; Tue, 19 Jun 2001 17:49:36 -0700 Message-ID: <20010620004936.8217.qmail@web11407.mail.yahoo.com> Received: from [216.183.18.189] by web11407.mail.yahoo.com; Tue, 19 Jun 2001 17:49:36 PDT Date: Tue, 19 Jun 2001 17:49:36 -0700 (PDT) From: Rayson Ho Subject: Re: sgicc on linux ia64 To: Ram Menon , pro64-support@oss.sgi.com Cc: Ram Menon In-Reply-To: <200106192230.PAA06046@xena.informix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-pro64-support@oss.sgi.com Precedence: bulk I have my own IA64 box since last year and I've never used NUE before. I think NUE just emulates the IA64 system, so ideally you can use it on your Itanium machine. Rayson --- Ram Menon wrote: > Hi, > > Is sgicc binaries available to download on Redhat linux running on > Intel Itanium > machines ?. I am seeing NUE binaries on SGI Website. > > thanks > __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ From owner-pro64-support@oss.sgi.com Tue Jun 19 18:12:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5K1C0i28885 for pro64-support-outgoing; Tue, 19 Jun 2001 18:12:00 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5K1BxV28870 for ; Tue, 19 Jun 2001 18:11:59 -0700 Received: from cchkms.engr.sgi.com (cchkms.engr.sgi.com [130.62.180.48]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id DAA608605 for ; Wed, 20 Jun 2001 03:11:57 +0200 (CEST) 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 SAA19579; Tue, 19 Jun 2001 18:09:16 -0700 (PDT) From: "Ross A. Towle" Message-Id: <10106191809.ZM19557@cchkms.engr.sgi.com> Date: Tue, 19 Jun 2001 18:09:15 -0700 In-Reply-To: rmenon@informix.com (Ram Menon) "sgicc on linux ia64" (Jun 19, 3:30pm) References: <200106192230.PAA06046@xena.informix.com> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: rmenon@informix.com (Ram Menon), pro64-support@oss.sgi.com Subject: Re: sgicc on linux ia64 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Those binaries can be run on a RedHat Linux on an Intel Itanium machine. This has been true for all the versions of Pro64 that have been released on the oss.sgi.com website. It is also the case that they can also work under NUE. -Ross On Jun 19, 3:30pm, Ram Menon wrote: > Subject: sgicc on linux ia64 > Hi, > > Is sgicc binaries available to download on Redhat linux running on Intel Itanium > machines ?. I am seeing NUE binaries on SGI Website. > > thanks >-- End of excerpt from Ram Menon From owner-pro64-support@oss.sgi.com Thu Jun 21 08:26:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5LFQHj10208 for pro64-support-outgoing; Thu, 21 Jun 2001 08:26:17 -0700 Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5LFQGV10205 for ; Thu, 21 Jun 2001 08:26:16 -0700 Received: from zeta.dmz-eu.st.com (zeta.dmz-eu.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with SMTP id DA7354A63 for ; Thu, 21 Jun 2001 15:26:08 +0000 (GMT) Received: by zeta.dmz-eu.st.com (STMicroelectronics, from userid 0) id F41914BF3; Thu, 21 Jun 2001 15:25:52 +0000 (GMT) Received: from thistle.bri.st.com (localhost [127.0.0.1]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 92712184F for ; Thu, 21 Jun 2001 15:25:52 +0000 (GMT) Received: from [164.129.14.43] (helo=absolut) by thistle.bristol.st.com with esmtp (Exim 3.03 #5) id 15D6L6-0003QS-00 for pro64-support@oss.sgi.com; Thu, 21 Jun 2001 16:25:48 +0100 Received: from bowersa (helo=localhost) by absolut with local-esmtp (Exim 3.03 #5) id 15D6L6-0005PQ-00 for pro64-support@oss.sgi.com; Thu, 21 Jun 2001 16:25:48 +0100 Date: Thu, 21 Jun 2001 16:25:48 +0100 (BST) From: Antony Bowers X-Sender: bowersa@absolut To: pro64-support@oss.sgi.com Subject: Latent bug in cg? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pro64-support@oss.sgi.com Precedence: bulk I've been exploring the source of the Pro64 code generator. File be/cg/whirl2ops.cxx has the following code: Convert_WHIRL_To_OPs(WN * tree) { ... CGRIN *cgrin; ... switch ( WN_opcode( tree ) ) { ... case OPC_REGION: Compiling_Proper_REGION = TRUE; if ( RID_level( rid ) < RL_CG ) { /* it is WHIRL */ ... } else { /* it is OPs */ ... CGRIN_entry( cgrin ) = REGION_First_BB; stmt = NULL; } break; ... } ... } It looks as though the variable cgrin is being used uninitialised in the line CGRIN_entry( cgrin ) = REGION_First_BB; and if so, there are more uninitialised uses further down. Presumably this case of revisiting a region already translated to OPS never arises in practice. Just thought I'd report this to the list in case the information is of value. Tony -- Antony Bowers, STMicroelectronics, Bristol, UK From owner-pro64-support@oss.sgi.com Mon Jun 25 03:31:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5PAVFZ23795 for pro64-support-outgoing; Mon, 25 Jun 2001 03:31:15 -0700 Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5PAV9V23785 for ; Mon, 25 Jun 2001 03:31:14 -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.40 2001/06/06 21:14:49 root Exp $) with SMTP id KAA00468 for ; Mon, 25 Jun 2001 10:31:09 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.48.29]) by 132.233.48.202 (Norton AntiVirus for Internet Email Gateways 1.0) ; Mon, 25 Jun 2001 10:31:08 0000 (GMT) Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Jun 2001 03:31:07 -0700 Message-ID: From: "Kakulavarapu, Prasad" To: "'pro64-support@oss.sgi.com'" Subject: Stack Frame allocation Date: Mon, 25 Jun 2001 03:31:05 -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, I am using sgicc to run an application with some hand-coded assembly functions. SGIcc ver is 0.01.0-13, building the app on my Itanium system running Linux kernel 2.4.1-010131-8. Problem: segmentation Fault (Core dumped) I use the alloc statement in the handcoded assembly to allocate a stack frame; alloc r36=ar.pfs,0,6,4,0 This alloc statement is from code generated by SGIcc at the start of a function called with foo(void* a, void* b, void* c, void*d), which itself calls another function with 3 args - foo2(void* a, int b, int c). When run, there occurs a Seg fault at the alloc statement in the assembly function. From the disassembly, this statement looks like this: alloc r36=ar.pfs,10,6,0 Question: Why does the disassembly have a different stack allocation pattern than the source assembly. Secondly, any clues about the Seg fault at this statement? (this is the first statement in the assembly for foo() Apprecaite any help. Thanks, Prasad From owner-pro64-support@oss.sgi.com Mon Jun 25 06:37:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5PDbtr30881 for pro64-support-outgoing; Mon, 25 Jun 2001 06:37:55 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5PDbrV30878 for ; Mon, 25 Jun 2001 06:37:54 -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 GAA07010 for ; Mon, 25 Jun 2001 06:35:02 -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 JAA48801; Mon, 25 Jun 2001 09:36:36 -0400 (EDT) Date: Mon, 25 Jun 2001 09:36:36 -0400 (EDT) From: lesniak@sgihud.hudson.sgi.com (Ken Lesniak) Message-Id: <200106251336.JAA48801@sgihud.hudson.sgi.com> To: "'pro64-support@oss.sgi.com'" , "Kakulavarapu, Prasad" Subject: Re: Stack Frame allocation Reply-To: lesniak@sgihud.hudson.sgi.com Sender: owner-pro64-support@oss.sgi.com Precedence: bulk >Hello, > >I am using sgicc to run an application with some hand-coded assembly >functions. SGIcc ver is 0.01.0-13, building the app on my Itanium system >running Linux kernel 2.4.1-010131-8. > >Problem: segmentation Fault (Core dumped) >I use the alloc statement in the handcoded assembly to allocate a stack >frame; > alloc r36=ar.pfs,0,6,4,0 > >This alloc statement is from code generated by SGIcc at the start of a >function called with foo(void* a, void* b, void* c, void*d), which itself >calls another function with 3 args - foo2(void* a, int b, int c). > >When run, there occurs a Seg fault at the alloc statement in the assembly >function. From the disassembly, this statement looks like this: > alloc r36=ar.pfs,10,6,0 > >Question: Why does the disassembly have a different stack allocation pattern >than the source assembly. Secondly, any clues about the Seg fault at this >statement? (this is the first statement in the assembly for foo() >From the Intel documentation, you find that that the assembler notation for the alloc instruction has one more operand than the actual machine instruction. These sentences from the alloc description are relevant: The size of the local region (sol) is given by i + l. There is no real distinction between inputs and locals. They are given as separate operands in the instruction only as a hint to the assembler about how the local registers are to be used. So once you assemble the instruction, the values of i and l are lost You only have the sum. A dissassembler cannot reconstruct the original instruction exactly. However, in my opinion, disassembing the instruction with one less argument seems bogus to me as it is not clear, at least to me, what the arguments are. I think it would have been better to generate the original form, but always leaving one of i or l zero. I may be wrong, but I doubt the assembler will accept the form generated by the dissassembler. >Apprecaite any help. >Thanks, >Prasad As to your segmentation fault, I unfortunately have no clues for you. Ken From owner-pro64-support@oss.sgi.com Mon Jun 25 06:50:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5PDodX30989 for pro64-support-outgoing; Mon, 25 Jun 2001 06:50:39 -0700 Received: from mail.ee.gatech.edu (mail.ee.gatech.edu [130.207.225.105]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5PDobV30986 for ; Mon, 25 Jun 2001 06:50:38 -0700 Received: from magic.ece-int.gatech.edu.ece.gatech.edu (IDENT:hardnett@magic.ece-int.gatech.edu [192.168.10.206]) by mail.ee.gatech.edu (8.11.3/8.11.0) with SMTP id f5PDoaT23313 for ; Mon, 25 Jun 2001 09:50:36 -0400 (EDT) From: "Charles R. Hardnett" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15159.16643.507376.91718@magic.ece-int.gatech.edu> Date: Mon, 25 Jun 2001 09:47:47 -0400 (EDT) To: pro64-support@oss.sgi.com Subject: C to Whirl X-Mailer: VM 6.72 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Reply-To: hardnett@cc.gatech.edu Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Hello, I have a question that involves the C to Whirl generation. I am using the whirl2C module, and noticed a bug with code such as the following: struct stat sbuf; if (sbuf.st_mode) { printf("hello"); } The above code comes out of pro64 after whirl2c translation to look something like: if((_UINT32)(*(struct stat0 { _UINT64 st_dev; _UINT32 st_ino; _INT32 __pad1; _UINT32 st_mode; _UINT32 st_nlink; _UINT32 st_uid; _UINT32 st_gid; _UINT64 st_rdev; _INT64 st_size; _INT64 st_atime; _INT64 st_mtime; _INT64 st_ctime; _INT32 st_blocks; _INT32 __pad2; _UINT32 st_blksize; _INT32 __pad3; _INT64 __unused[6LL]; } *)(((_INT8 *) & sbuf) + 16LL)) != 0U) { printf((const _INT8 *)(_INT8(*)[6LL]) "hello"); } The problem of course is cast contains a declaration of the struct, and not just the name of the struct. I have tracked down the problem to where this only occurs when a struct field is accessed within a cond exp i.e. within while, if, for, etc. I have also convinced myself that the problem is not in the whirl2c conversion because it appears that whirl2C is only outputing the token information that is stored in the WN for this object's type. Therefore, it appears that the problem is the translation from C to whirl by GFEC is most likely the culprit. My questions are: 1. Is there anyone else looking at the whirl2c module that may have run into this problem? 2. If not, does anyone have any good information on GFEC and how its exprs are stored? operated on to create the whirl? I was looking at the code this weekend, and could use any documentation anyone may have on it. Thanks, Charles -- -------------------------------------------------------------------- Charles R. Hardnett www.spelman.edu/~hardnett From owner-pro64-support@oss.sgi.com Mon Jun 25 09:47:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5PGlK302312 for pro64-support-outgoing; Mon, 25 Jun 2001 09:47:20 -0700 Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5PGlHV02309 for ; Mon, 25 Jun 2001 09:47:17 -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.40 2001/06/06 21:14:49 root Exp $) with SMTP id QAA00599; Mon, 25 Jun 2001 16:47:15 GMT Received: from fmsmsx18.intel.com ([132.233.48.18]) by 132.233.48.202 (Norton AntiVirus for Internet Email Gateways 1.0) ; Mon, 25 Jun 2001 16:47:12 0000 (GMT) Received: by fmsmsx18.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Jun 2001 09:47:11 -0700 Message-ID: From: "Kakulavarapu, Prasad" To: "'lesniak@sgihud.hudson.sgi.com'" , "'pro64-support@oss.sgi.com'" , "Kakulavarapu, Prasad" Subject: RE: Stack Frame allocation Date: Mon, 25 Jun 2001 09:47:08 -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 I checked that the assembler does not accept three parameters (instead of four) for the alloc statement. we still need the distinct i,l,o,r fields. But surprisingly, the size of the local frame (i+l) from the disassembler is 10, while the assembler alloc statement specifies only 6. Also, I don;t understand the o field in the disassembler - 6, when I have just 4 o/p in the assembler. Compare the following: Assembler: alloc r36=ar.pfs,0,6,4,0 Disassembler: alloc r36=ar.pfs,10,6,0 Thanks, Prasad > -----Original Message----- > From: lesniak@sgihud.hudson.sgi.com [SMTP:lesniak@sgihud.hudson.sgi.com] > Sent: Monday, June 25, 2001 6:37 AM > To: 'pro64-support@oss.sgi.com'; Kakulavarapu, Prasad > Subject: Re: Stack Frame allocation > > >Hello, > > > >I am using sgicc to run an application with some hand-coded assembly > >functions. SGIcc ver is 0.01.0-13, building the app on my Itanium system > >running Linux kernel 2.4.1-010131-8. > > > >Problem: segmentation Fault (Core dumped) > >I use the alloc statement in the handcoded assembly to allocate a stack > >frame; > > alloc r36=ar.pfs,0,6,4,0 > > > >This alloc statement is from code generated by SGIcc at the start of a > >function called with foo(void* a, void* b, void* c, void*d), which itself > >calls another function with 3 args - foo2(void* a, int b, int c). > > > >When run, there occurs a Seg fault at the alloc statement in the assembly > >function. From the disassembly, this statement looks like this: > > alloc r36=ar.pfs,10,6,0 > > > >Question: Why does the disassembly have a different stack allocation > pattern > >than the source assembly. Secondly, any clues about the Seg fault at this > >statement? (this is the first statement in the assembly for foo() > > From the Intel documentation, you find that that the assembler notation > for the alloc instruction has one more operand than the actual machine > instruction. These sentences from the alloc description are relevant: > > The size of the local region (sol) is given by i + l. > There is no real distinction between inputs and locals. > They are given as separate operands in the instruction > only as a hint to the assembler about how the local > registers are to be used. > > So once you assemble the instruction, the values of i and l are lost > You only have the sum. A dissassembler cannot reconstruct the original > instruction exactly. > > However, in my opinion, disassembing the instruction with one less > argument seems bogus to me as it is not clear, at least to me, > what the arguments are. I think it would have been better > to generate the original form, but always leaving one of i or l zero. > I may be wrong, but I doubt the assembler will accept the form > generated by the dissassembler. > > >Apprecaite any help. > >Thanks, > >Prasad > > As to your segmentation fault, I unfortunately have no clues for you. > > Ken From owner-pro64-support@oss.sgi.com Mon Jun 25 10:28:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5PHSdP02975 for pro64-support-outgoing; Mon, 25 Jun 2001 10:28:39 -0700 Received: from ganymede.or.intel.com (jffdns01.or.intel.com [134.134.248.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5PHScV02972 for ; Mon, 25 Jun 2001 10:28:38 -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.40 2001/06/06 21:14:49 root Exp $) with SMTP id RAA23857; Mon, 25 Jun 2001 17:28:36 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, 25 Jun 2001 17:28:35 0000 (GMT) Received: by orsmsx28.jf.intel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Jun 2001 10:28:34 -0700 Message-ID: <9287DC1579B0D411AA2F009027F44C3F0ABD0559@FMSMSX41> From: "Chan, Sun C" To: "'hardnett@cc.gatech.edu'" , pro64-support@oss.sgi.com Subject: RE: C to Whirl Date: Mon, 25 Jun 2001 10:28: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 > -----Original Message----- > From: Charles R. Hardnett [mailto:hardnett@cc.gatech.edu] > Sent: Monday, June 25, 2001 6:48 AM > To: pro64-support@oss.sgi.com > Subject: C to Whirl > > > > > Hello, > > I have a question that involves the C to Whirl generation. I am using > the whirl2C module, and noticed a bug with code such as the following: > > > struct stat sbuf; > > if (sbuf.st_mode) { > printf("hello"); > } > > > The above code comes out of pro64 after whirl2c translation to look > something like: > > if((_UINT32)(*(struct stat0 { > _UINT64 st_dev; > _UINT32 st_ino; > _INT32 __pad1; > _UINT32 st_mode; > _UINT32 st_nlink; > _UINT32 st_uid; > _UINT32 st_gid; > _UINT64 st_rdev; > _INT64 st_size; > _INT64 st_atime; > _INT64 st_mtime; > _INT64 st_ctime; > _INT32 st_blocks; > _INT32 __pad2; > _UINT32 st_blksize; > _INT32 __pad3; > _INT64 __unused[6LL]; > } *)(((_INT8 *) & sbuf) + 16LL)) != 0U) > { > printf((const _INT8 *)(_INT8(*)[6LL]) "hello"); > } > > > The problem of course is cast contains a declaration of the struct, > and not just the name of the struct. I have tracked down the problem > to where this only occurs when a struct field is accessed within a > cond exp i.e. within while, if, for, etc. > > I have also convinced myself that the problem is not in the whirl2c > conversion because it appears that whirl2C is only outputing the token > information that is stored in the WN for this object's > type. Therefore, it appears that the problem is the translation from C > to whirl by GFEC is most likely the culprit. Whirl is just an IR, the problem is not in WHIRL, its in Whirl2c itself on how it handles type info while outputing the IR back into C. Sun From owner-pro64-support@oss.sgi.com Mon Jun 25 10:39:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5PHdK303318 for pro64-support-outgoing; Mon, 25 Jun 2001 10:39:20 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5PHdJV03315 for ; Mon, 25 Jun 2001 10:39:19 -0700 Received: from dsl-proof.corp.sgi.com (dsl-proof.corp.sgi.com [192.102.142.250]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id KAA01514 for ; Mon, 25 Jun 2001 10:36:27 -0700 (PDT) mail_from (dlstephe@sgi.com) Received: from sgi.com (localhost [127.0.0.1]) by dsl-proof.corp.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id KAA19305; Mon, 25 Jun 2001 10:47:33 -0700 (PDT) Message-ID: <3B377935.9FB673FD@sgi.com> Date: Mon, 25 Jun 2001 10:47:33 -0700 From: David Stephenson Organization: SGI -- Compilers X-Mailer: Mozilla 4.76C-SGI [en] (X11; I; IRIX 6.5 IP32) X-Accept-Language: en MIME-Version: 1.0 To: hardnett@cc.gatech.edu CC: pro64-support@oss.sgi.com Subject: Re: C to Whirl References: <15159.16643.507376.91718@magic.ece-int.gatech.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pro64-support@oss.sgi.com Precedence: bulk "Charles R. Hardnett" wrote: > The problem of course is cast contains a declaration of the struct, > and not just the name of the struct. I have tracked down the problem > to where this only occurs when a struct field is accessed within a > cond exp i.e. within while, if, for, etc. One guess: whirl2c may not be correctly recognizing and handling field_id. - David -- David Stephenson http://reality.sgi.com/dlstephe_engr/ From owner-pro64-support@oss.sgi.com Mon Jun 25 11:10:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5PIALE03740 for pro64-support-outgoing; Mon, 25 Jun 2001 11:10:21 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5PIAJV03737 for ; Mon, 25 Jun 2001 11:10:19 -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 UAA185606 for ; Mon, 25 Jun 2001 20:10:16 +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 OAA52217; Mon, 25 Jun 2001 14:08:55 -0400 (EDT) Date: Mon, 25 Jun 2001 14:08:55 -0400 (EDT) From: lesniak@sgihud.hudson.sgi.com (Ken Lesniak) Message-Id: <200106251808.OAA52217@sgihud.hudson.sgi.com> To: "Kakulavarapu, Prasad" , "'pro64-support@oss.sgi.com'" , "Kakulavarapu, Prasad" Subject: RE: Stack Frame allocation Reply-To: lesniak@sgihud.hudson.sgi.com Sender: owner-pro64-support@oss.sgi.com Precedence: bulk >I checked that the assembler does not accept three parameters (instead of >four) for the alloc statement. we still need the distinct i,l,o,r fields. > >But surprisingly, the size of the local frame (i+l) from the disassembler is >10, while the assembler alloc statement specifies only 6. Also, I don;t >understand the o field in the disassembler - 6, when I have just 4 o/p in >the assembler. Compare the following: > > Assembler: alloc r36=ar.pfs,0,6,4,0 > Disassembler: alloc r36=ar.pfs,10,6,0 > >Thanks, >Prasad The assembler use this format: alloc r1=ar.pfs,i,l,o,r The actual machine instruction encodes 3 parameters for the frame specification: sor, sol and sof. They are determined as follows: sof = i+l+o sol = i+l sor = r>>3 >From your source: sof = 0+6+4 = 10 sol = 0+6 = 6 sor = 0>>3 = 0 That matches what the disassembler is doing, so we have just derived that it prints the machine instruction as: alloc r1=ar.pfs,sof,sol,sor All looks well to me. Ken From owner-pro64-support@oss.sgi.com Mon Jun 25 11:44:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5PIidS04367 for pro64-support-outgoing; Mon, 25 Jun 2001 11:44:39 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5PIiaV04364 for ; Mon, 25 Jun 2001 11:44:37 -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 UAA182079 for ; Mon, 25 Jun 2001 20:44:34 +0200 (CEST) mail_from (murthy@sgi.com) Received: from sgi.com (gaea.engr.sgi.com [130.62.180.97]) by cthulhu.engr.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id LAA18939; Mon, 25 Jun 2001 11:43:16 -0700 (PDT) Message-ID: <3B378644.8F98A6B3@sgi.com> Date: Mon, 25 Jun 2001 11:43:16 -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: hardnett@cc.gatech.edu CC: pro64-support@oss.sgi.com Subject: Re: C to Whirl References: <15159.16643.507376.91718@magic.ece-int.gatech.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pro64-support@oss.sgi.com Precedence: bulk "Charles R. Hardnett" wrote: > Hello, > > I have a question that involves the C to Whirl generation. I am using > the whirl2C module, and noticed a bug with code such as the following: > > struct stat sbuf; > > if (sbuf.st_mode) { > printf("hello"); > } > > The above code comes out of pro64 after whirl2c translation to look > something like: > > if((_UINT32)(*(struct stat0 { > _UINT64 st_dev; > _UINT32 st_ino; > _INT32 __pad1; > _UINT32 st_mode; > _UINT32 st_nlink; > _UINT32 st_uid; > _UINT32 st_gid; > _UINT64 st_rdev; > _INT64 st_size; > _INT64 st_atime; > _INT64 st_mtime; > _INT64 st_ctime; > _INT32 st_blocks; > _INT32 __pad2; > _UINT32 st_blksize; > _INT32 __pad3; > _INT64 __unused[6LL]; > } *)(((_INT8 *) & sbuf) + 16LL)) != 0U) > { > printf((const _INT8 *)(_INT8(*)[6LL]) "hello"); > } > > The problem of course is cast contains a declaration of the struct, > and not just the name of the struct. I have tracked down the problem > to where this only occurs when a struct field is accessed within a > cond exp i.e. within while, if, for, etc. > > I have also convinced myself that the problem is not in the whirl2c > conversion because it appears that whirl2C is only outputing the token > information that is stored in the WN for this object's > type. Therefore, it appears that the problem is the translation from C > to whirl by GFEC is most likely the culprit. > The problem is with whirl2c. It has not been modified to reflect field_id usage. > > My questions are: > > 1. Is there anyone else looking at the whirl2c module that may have > run into this problem? > > 2. If not, does anyone have any good information on GFEC and how > its exprs are stored? operated on to create the whirl? I was looking > at the code this weekend, and could use any documentation anyone may > have on it. > The WHIRL generation in gfec is done on the fly. Unlike gfecc,(which works on a tree representation for the entire compilation unit), gfec intercepts calls during the gnu IR generation (these are under #ifdef SGI_MONGOSE in the gccfe/gnu directory). This interception is done at a statement level (handled in wfe_stmt.cxx), which will in turn handle expressions (handled in wfe_expr.cxx). > > Thanks, > > Charles > > -- > -------------------------------------------------------------------- > Charles R. Hardnett www.spelman.edu/~hardnett Murthy From owner-pro64-support@oss.sgi.com Mon Jun 25 15:03:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5PM35G16306 for pro64-support-outgoing; Mon, 25 Jun 2001 15:03:05 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5PM33V16297 for ; Mon, 25 Jun 2001 15:03:03 -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 PAA28527 for ; Mon, 25 Jun 2001 15:02:57 -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 OAA57855; Mon, 25 Jun 2001 14:58:54 -0700 (PDT) Date: Mon, 25 Jun 2001 14:58:54 -0700 (PDT) From: mpm@rohi.engr.sgi.com (Michael Murphy) Message-Id: <200106252158.OAA57855@rohi.engr.sgi.com> To: pro64-support@oss.sgi.com, Antony Bowers Subject: Re: Latent bug in cg? Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Date: Thu, 21 Jun 2001 16:25:48 +0100 (BST) From: Antony Bowers To: pro64-support@oss.sgi.com Subject: Latent bug in cg? I've been exploring the source of the Pro64 code generator. File be/cg/whirl2ops.cxx has the following code: Convert_WHIRL_To_OPs(WN * tree) { ... CGRIN *cgrin; ... switch ( WN_opcode( tree ) ) { ... case OPC_REGION: Compiling_Proper_REGION = TRUE; if ( RID_level( rid ) < RL_CG ) { /* it is WHIRL */ ... } else { /* it is OPs */ ... CGRIN_entry( cgrin ) = REGION_First_BB; stmt = NULL; } break; ... } ... } It looks as though the variable cgrin is being used uninitialised in the line CGRIN_entry( cgrin ) = REGION_First_BB; and if so, there are more uninitialised uses further down. Presumably this case of revisiting a region already translated to OPS never arises in practice. You are right on both counts. This is a source bug, but one that never gets triggered. Regions were an idea we worked on to balance the problems of compile speed and optimization. The idea was that when you have large routines, break it into regions and optimize it a region at a time. There were some promising results from this, but the work was never completed, and has since been dropped due to a lack of resources. So some of the region usage that you see is never actually executed (however, there are some actual uses of regions still generated, for exception handling and mp code, but those are special cases that do not affect the flow of code generation). Also, the way regions usually worked, you would be passing in whirl to Convert_WHIRL_To_OPS, and then inside that whirl there might be some region code that was already processed to ops, but that wouldn't be at the top-level. Nonetheless, thanks for the careful reading of the code and pointing this out. I will fix this and/or add a comment about it being obsolete. -- Mike Murphy -- mpm@sgi.com -- quote of the day: -- Be patient with the faults of others; -- they have to be patient with yours. From owner-pro64-support@oss.sgi.com Tue Jun 26 01:10:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5Q8ACQ23445 for pro64-support-outgoing; Tue, 26 Jun 2001 01:10:12 -0700 Received: from mail.ict.ac.cn ([159.226.39.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5Q8AAV23441 for ; Tue, 26 Jun 2001 01:10:11 -0700 Received: (qmail 18184 invoked from network); 26 Jun 2001 08:05:33 -0000 Received: from unknown (HELO act200) (159.226.40.246) by 159.226.39.4 with SMTP; 26 Jun 2001 08:05:33 -0000 Message-ID: <019601c0fe17$e5eecfb0$260379c8@act200> From: "Liu Yang" To: "pro64" Subject: A potentail bug in hyperblock formation? Date: Tue, 26 Jun 2001 16:13:35 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0193_01C0FE5A.F3B067B0" 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 This is a multi-part message in MIME format. ------=_NextPart_000_0193_01C0FE5A.F3B067B0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hello, If a goto BB is duplicated,there maybe a mistake in the=20 Fixup_Arcs function: if (BB_Fall_Thru_Successor(pred) =3D=3D old_bb) { Link_Pred_Succ_with_Prob(dup, new_bb, BBLIST_prob(blsucc)); } else if (BB_kind(dup) =3D=3D BBKIND_LOGIF) { Target_Cond_Branch(dup, new_bb, BBLIST_prob(blsucc)); } else { ... ... } } } In the above code,I think the following statements should be added after Link_Pred_Succ_With_Prob(... ...) : if (BB_kind(dup) =3D=3D BBKIND_GOTO) { BB_Remove_Branch(dup); } Though goto BB's fallthrough is its succ make the goto BB no use,but sometimes it really happened.Is this correct? Thanks! With my best regards, Liu Yang Advanced Compiler Lab Institute of Computing Technology Chinese Academy of Science E-Mail : ly@ict.ac.cn ------=_NextPart_000_0193_01C0FE5A.F3B067B0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hello,
If a = goto BB is=20 duplicated,there maybe a mistake in = the=20
Fixup_Arcs function:
 
    if = (BB_Fall_Thru_Successor(pred)=20 =3D=3D old_bb) {
       =20  Link_Pred_Succ_with_Prob(dup, new_bb,=20 BBLIST_prob(blsucc));
     } else if = (BB_kind(dup) =3D=3D=20 BBKIND_LOGIF) {
       =20 Target_Cond_Branch(dup, new_bb,=20 BBLIST_prob(blsucc));
      } else = {
        ...=20 ...
      }
    = }
 =20 }
In the above code,I think the following = statements=20 should be
added after = Link_Pred_Succ_With_Prob(... ...)=20 :
 
if (BB_kind(dup) =3D=3D BBKIND_GOTO)=20 {
       =20 BB_Remove_Branch(dup);
 }
 
Though goto BB's fallthrough is its = succ make the=20 goto BB
no use,but sometimes it really=20 happened.Is this = correct?
 
Thanks!
 
With my best regards,
Liu Yang
 
Advanced Compiler Lab
Institute of = Computing=20 Technology
Chinese Academy of Science
E-Mail :  ly@ict.ac.cn
------=_NextPart_000_0193_01C0FE5A.F3B067B0-- From owner-pro64-support@oss.sgi.com Thu Jun 28 13:22:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5SKMJi16269 for pro64-support-outgoing; Thu, 28 Jun 2001 13:22:19 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5SKMHV16266 for ; Thu, 28 Jun 2001 13:22:17 -0700 Received: from dsl-proof.corp.sgi.com (dsl-proof.corp.sgi.com [192.102.142.250]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id NAA04843 for ; Thu, 28 Jun 2001 13:19:28 -0700 (PDT) mail_from (dlstephe@sgi.com) Received: from sgi.com (localhost [127.0.0.1]) by dsl-proof.corp.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id NAA01570; Thu, 28 Jun 2001 13:30:54 -0700 (PDT) Message-ID: <3B3B93FD.B0717CDA@sgi.com> Date: Thu, 28 Jun 2001 13:30:53 -0700 From: David Stephenson Organization: SGI -- Compilers X-Mailer: Mozilla 4.76C-SGI [en] (X11; I; IRIX 6.5 IP32) X-Accept-Language: en MIME-Version: 1.0 To: pro64-support@oss.sgi.com Subject: Some fixes to v0.13 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pro64-support@oss.sgi.com Precedence: bulk Below are a few bug fixes that didn't make it into the SGI Pro64 version 0.13 release. Each fix is only a few lines of code. The problems arise only occasionally, but these changes still might prove helpful to some. The line numbers below might not exactly match the 0.13 source. - David ---------------------------------------- (1) LNO scalar renaming needs to reset field_id to zero. In the file be/lno/ff_utils.cxx, near the end of the function scalar_rename, replace: *************** *** 650,656 **** OPCODE_rtype(scalar_op), Promote_Type(OPCODE_desc(scalar_op)))); WN_set_ty(scalar_ref,Be_Type_Tbl(Promote_Type(desc))); < WN_offset(scalar_ref)=new_symbol.WN_Offset(); if (Alias_Mgr) { Create_alias(Alias_Mgr,scalar_ref); } --- 650,656 ---- OPCODE_rtype(scalar_op), Promote_Type(OPCODE_desc(scalar_op)))); WN_set_ty(scalar_ref,Be_Type_Tbl(Promote_Type(desc))); > WN_set_field_id(scalar_ref, 0); // fix 819155 if (Alias_Mgr) { Create_alias(Alias_Mgr,scalar_ref); } ---------------------------------------- (2) CICSE_Transform segfaults when a loop-invariant TN value is stored. In be/cg/cio_rwtran.cxx, in the middle of the body of the method CIO_RWTRAN::CICSE_Transform, replace: *************** *** 2524,2530 **** // If source TN occurs later as a result, then new TN is required // NOT ALWAYS NECESSARY! IMPROVE THIS! INT tn_index = hTN_MAP32_Get( tn_last_op, change.new_tns[0] ); < if ( OP_Precedes( change.source, cicse_table[tn_index].op ) ) change.new_tns[0] = Build_TN_Like( change.new_tns[0] ); } else { --- 2524,2531 ---- // If source TN occurs later as a result, then new TN is required // NOT ALWAYS NECESSARY! IMPROVE THIS! INT tn_index = hTN_MAP32_Get( tn_last_op, change.new_tns[0] ); > if ( tn_index == 0 || > OP_Precedes( change.source, cicse_table[tn_index].op ) ) change.new_tns[0] = Build_TN_Like( change.new_tns[0] ); } else { ---------------------------------------- (3) Undo an incorrect change to IVR. In the file be/opt/opt_ivr.cxx, in the body of the method IVR::Ident_all_iv_cands, replace: *************** *** 1032,1038 **** // the type of the IV is the type of increment expr. MTYPE dtype; if (incr->Defstmt()) < dtype = incr->Defstmt()->Rhs()->Dsctyp(); else dtype = incr->Defphi()->OPND(0)->Defstmt()->Rhs()->Dtyp(); --- 1032,1038 ---- // the type of the IV is the type of increment expr. MTYPE dtype; if (incr->Defstmt()) > dtype = incr->Defstmt()->Rhs()->Dtyp(); else dtype = incr->Defphi()->OPND(0)->Defstmt()->Rhs()->Dtyp(); ---------------------------------------- (4) If Fix_zero_version generates a new version, the volatile flag should be set correctly. In the file be/opt/opt_find.cxx, in each of the methods CODEMAP::Fix_zero_version, insert: *************** *** 783,789 **** if (phi_res->Is_flag_set(CF_MADEUP_TYPE)) retval->Set_flag(CF_MADEUP_TYPE); // TODO: Probably need to set a bunch of *retval's fields // here. See opt_ivr.cxx for examples. --- 783,794 ---- if (phi_res->Is_flag_set(CF_MADEUP_TYPE)) retval->Set_flag(CF_MADEUP_TYPE); > // Fix 815093: Set volatile flag > if ( Opt_stab()->Is_volatile( phi_res->Aux_id() ) ) { > retval->Set_is_volatile(); > } > // TODO: Probably need to set a bunch of *retval's fields // here. See opt_ivr.cxx for examples. *************** *** 848,853 **** chi_opnd->Lod_ty(), chi_opnd->Field_id(), TRUE); // TODO: Probably need to set a bunch of *retval's fields // here. See opt_ivr.cxx for examples. --- 853,863 ---- chi_opnd->Lod_ty(), chi_opnd->Field_id(), TRUE); > > // Fix 815093: Set volatile flag > if ( Opt_stab()->Is_volatile( chi_opnd->Aux_id() ) ) { > retval->Set_is_volatile(); > } // TODO: Probably need to set a bunch of *retval's fields // here. See opt_ivr.cxx for examples. ----------------------------------------