From owner-pro64-contrib@oss.sgi.com Tue Jun 5 07:19:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f55EJti20441 for pro64-contrib-outgoing; Tue, 5 Jun 2001 07:19:55 -0700 Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f55EJqh20429 for ; Tue, 5 Jun 2001 07:19:53 -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 79D4F4AC5 for ; Tue, 5 Jun 2001 14:02:32 +0000 (GMT) Received: by zeta.dmz-eu.st.com (STMicroelectronics, from userid 0) id 4B6D94929; Tue, 5 Jun 2001 14:02:43 +0000 (GMT) Received: from thistle.bri.st.com (localhost [127.0.0.1]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id C5E89184E for ; Tue, 5 Jun 2001 14:02:42 +0000 (GMT) Received: from [164.129.14.93] (helo=HARPO) by thistle.bristol.st.com with smtp (Exim 3.03 #5) id 157HPi-0004Iq-00; Tue, 05 Jun 2001 15:02:30 +0100 From: "Benedict R. Gaster" To: "Pro64 Contrib" Cc: "Benedict. Gaster@St. Com" Subject: Porting the compiler to an ISA that does not support bundles. Date: Tue, 5 Jun 2001 15:07:24 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-pro64-contrib@oss.sgi.com Precedence: bulk Hello! We are currently looking into retargeting the Pro64 compiler to a ISA that is not VLIW and thus the processor does not provide support for bunding instructions into more than one slot pre-instruction cycle. To represent the fact that the processor does not support bundling by including the following in out analgous "common/targ_info/proc/ia64/proc_properties.cxx": bundles = PROC_Property_Create("has_bundles"); Processor_Group(bundles, PROCESSOR_UNDEFINED); Here we notice that there is no processor included, implying that no target support for bundles. Following on from this the packing of bundles, with respect to particular units, are captured in the analgous implementation of "common/targ_info/isa/ia64/isa_bundle.cxx". This, however, seems to raise some problems and some interesting questions. It would seem to make sense that as support for bundles is switched off, then it would not be necessary to provide implementation of "isa_bundle.cxx". Taking this approach causes, during the build of the targ_info directory, the a failure when trying to build "common/access/ti_bundle.c", which depends on tables provided by "isa_bundle.[ch]". It is possible to change the build system not to include, "common/access/ti_bundle.c" So it seems the simplest why to solve these problems is to provide an implementation analgous to "common/targ_info/isa/ia64/isa_bundles.cxx", however, the problem is that it cannot simply: int main() { ISA_Bundle_Begin(ARCHITECTURE, BUNDLE_WIDTH); ISA_Bundle_End(); } where BUNDLE_WIDTH is 32, which is the size, in bits, of our instructions. Building the "targ_info" gives the following error: ### Error: no bundle packing specification! This can be fixed by adding the following line: ISA_Bundle_Pack_Create(ISA_Bundle_Pack_Little_Endian); and then everything compiles ok. But is this enough for a processor that provides no support for bundles and thus requires no defining of groupings, registered through "Instruction_Exec_Unit_Group()"? Thanks for any information on this subject. cheers, ben. From owner-pro64-contrib@oss.sgi.com Tue Jun 5 07:48:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f55EmQG24591 for pro64-contrib-outgoing; Tue, 5 Jun 2001 07:48:26 -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 f55EmPh24586 for ; Tue, 5 Jun 2001 07:48:25 -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 HAA11922 for ; Tue, 5 Jun 2001 07:48:23 -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 KAA10679; Tue, 5 Jun 2001 10:47:06 -0400 (EDT) Date: Tue, 5 Jun 2001 10:47:06 -0400 (EDT) From: lesniak@sgihud.hudson.sgi.com (Ken Lesniak) Message-Id: <200106051447.KAA10679@sgihud.hudson.sgi.com> To: "Pro64 Contrib" , "Benedict R. Gaster" Subject: Re: Porting the compiler to an ISA that does not support bundles. Cc: "Benedict. Gaster@St. Com" Reply-To: lesniak@sgihud.hudson.sgi.com Sender: owner-pro64-contrib@oss.sgi.com Precedence: bulk >To represent the fact that the processor does not support bundling by >including the following in out analgous >"common/targ_info/proc/ia64/proc_properties.cxx": > > bundles = PROC_Property_Create("has_bundles"); > Processor_Group(bundles, > PROCESSOR_UNDEFINED); > >Here we notice that there is no processor included, implying that no target >support for bundles. That's exactly what you want to do. >Following on from this the packing of bundles, with respect to particular >units, are captured in the analgous implementation of >"common/targ_info/isa/ia64/isa_bundle.cxx". This, however, seems to raise >some problems and some interesting questions. It would seem to make sense >that as support for bundles is switched off, then it would not be necessary >to provide implementation of "isa_bundle.cxx". Taking this approach causes, >during the build of the targ_info directory, the a failure when trying to >build "common/access/ti_bundle.c", which depends on tables provided by >"isa_bundle.[ch]". > >It is possible to change the build system not to include, >"common/access/ti_bundle.c" > >So it seems the simplest why to solve these problems is to provide an >implementation analgous to "common/targ_info/isa/ia64/isa_bundles.cxx", >however, the problem is that it cannot simply: >... Try using this as a template for isa_bundles.cxx: ============================================================ #include #include "topcode.h" #include "isa_bundle_gen.h" main() { ISA_EXEC_UNIT_TYPE Any_Unit; // Any unit ISA_Bundle_Begin("your-arch-name-here", 32); /* ===== Specification for bundle packing ===== */ ISA_Bundle_Pack_Create(ISA_Bundle_Pack_Big_Endian); Pack_Slot(0, 0, 0, 32); /* ===== Specification for Any_Unit Type ===== */ Any_Unit = ISA_Exec_Unit_Type_Create("Any_Unit", NULL); Instruction_Exec_Unit_Group(Any_Unit, // // >>>>>>>>>>>>>>>>>> list ALL of your topcodes here <<<<<<<<<<<<<<<< // TOP_UNDEFINED); /* ===== Specification for template 0 ===== */ ISA_Bundle_Type_Create("any", "any", 1); Slot (0, Any_Unit); ISA_Bundle_End(); return 0; } ============================================================ Ken From owner-pro64-contrib@oss.sgi.com Tue Jun 5 17:56:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f560u7Z02789 for pro64-contrib-outgoing; Tue, 5 Jun 2001 17:56:07 -0700 Received: from mail.ict.ac.cn ([159.226.39.4]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f560u5h02786 for ; Tue, 5 Jun 2001 17:56:05 -0700 Received: (qmail 21363 invoked from network); 6 Jun 2001 00:51:16 -0000 Received: from unknown (HELO cathy) (@159.226.40.246) by 159.226.39.4 with SMTP; 6 Jun 2001 00:51:16 -0000 Message-ID: <002401c0ee23$a25bb8c0$230379c8@cathy> From: "Fu Chen" To: "Benedict R. Gaster" , "Pro64 Contrib" References: Subject: Re: Porting the compiler to an ISA that does not support bundles. Date: Wed, 6 Jun 2001 08:57:14 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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-contrib@oss.sgi.com Precedence: bulk Porting is far from a simple work of removing one or two files. While most the functions in ti_bundle.c are called on behave of Handle_All_Hazards, which is the function that actually do bundling after IGLS is done. You can try to remove this functions since there is no bundle feature in your target. And if you really want to remove isa_bundle.cxx, there will be another problem in Assemble_Bundles (cgemit.cxx) Since it is only called when ISA_MAX_SLOTS>1, you can simply remove it. Turning off bundling will also cause some problems in SWP. While I'm not quite familar with that part. There must be more. Good luck! ----- Original Message ----- From: "Benedict R. Gaster" To: "Pro64 Contrib" Cc: "Benedict. Gaster@St. Com" Sent: Tuesday, June 05, 2001 10:07 PM Subject: Porting the compiler to an ISA that does not support bundles. > Hello! > > We are currently looking into retargeting the Pro64 compiler to a ISA that > is not VLIW and thus the processor does not provide support for bunding > instructions into more than one slot pre-instruction cycle. > > To represent the fact that the processor does not support bundling by > including the following in out analgous > "common/targ_info/proc/ia64/proc_properties.cxx": > > bundles = PROC_Property_Create("has_bundles"); > Processor_Group(bundles, > PROCESSOR_UNDEFINED); > > Here we notice that there is no processor included, implying that no target > support for bundles. > > Following on from this the packing of bundles, with respect to particular > units, are captured in the analgous implementation of > "common/targ_info/isa/ia64/isa_bundle.cxx". This, however, seems to raise > some problems and some interesting questions. It would seem to make sense > that as support for bundles is switched off, then it would not be necessary > to provide implementation of "isa_bundle.cxx". Taking this approach causes, > during the build of the targ_info directory, the a failure when trying to > build "common/access/ti_bundle.c", which depends on tables provided by > "isa_bundle.[ch]". > > It is possible to change the build system not to include, > "common/access/ti_bundle.c" > > So it seems the simplest why to solve these problems is to provide an > implementation analgous to "common/targ_info/isa/ia64/isa_bundles.cxx", > however, the problem is that it cannot simply: > > int main() > { > ISA_Bundle_Begin(ARCHITECTURE, BUNDLE_WIDTH); > > ISA_Bundle_End(); > } > > where BUNDLE_WIDTH is 32, which is the size, in bits, of our instructions. > Building the "targ_info" gives the following error: > > ### Error: no bundle packing specification! > > This can be fixed by adding the following line: > > ISA_Bundle_Pack_Create(ISA_Bundle_Pack_Little_Endian); > > and then everything compiles ok. > > But is this enough for a processor that provides no support for bundles and > thus requires no defining of groupings, registered through > "Instruction_Exec_Unit_Group()"? > > Thanks for any information on this subject. > > > cheers, > > ben. > > From owner-pro64-contrib@oss.sgi.com Tue Jun 12 03:27:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5CARpx24771 for pro64-contrib-outgoing; Tue, 12 Jun 2001 03:27:51 -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 f5CARmV24765 for ; Tue, 12 Jun 2001 03:27:48 -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 66431492E for ; Tue, 12 Jun 2001 10:27:40 +0000 (GMT) Received: by zeta.dmz-eu.st.com (STMicroelectronics, from userid 0) id AD20848C6; Tue, 12 Jun 2001 10:27:40 +0000 (GMT) Received: from thistle.bri.st.com (localhost [127.0.0.1]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 3E6161851 for ; Tue, 12 Jun 2001 10:27:40 +0000 (GMT) Received: from [164.129.14.93] (helo=HARPO) by thistle.bristol.st.com with smtp (Exim 3.03 #5) id 159lOc-00047R-00 for pro64-contrib@oss.sgi.com; Tue, 12 Jun 2001 11:27:38 +0100 From: "Benedict R. Gaster" To: "Pro64 Contrib" Subject: ELF binaries when only wishing to produce assembler code... Date: Tue, 12 Jun 2001 11:32:32 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-pro64-contrib@oss.sgi.com Precedence: bulk Hello! I am currently involved in looking at the process of porting the Pro64 to new 32bit architecture and have some difficulty in completly understanding the ELF requirements. The problem is that we are only interested in producing assembler suitable for input into a version of GAS and not with producing object modules directly. However, it is by no means clear if a Pro64 compiler can be built to target the assembler only. There are a number of header files releated to ELF: ./common/com/config_elf_targ.h --- prototypes API for target/machine ELF configuration. ./common/com/em_elf.h --- prototypes API for writing ELF module. Corresponding C++ source files are provided in: ./common/com/ia64/config_elf_targ.cxx ./common/com/ia64/targ_em_elf.cxx which provide, ia64, implementations of the specified ELF APIs. These two files files, along with an additional header also defined in common/com/ia64, are straightforward to implement for a new architecture. The following header defines some C++ typedefs used to instantiate templates that are based on the format of an Elf object and requires no porting: ./common/com/ir_elf.h ./include/cmplrs/elf_interfaces.h --- provides a consumer API to the .MIPS.interfaces ELF section ./include/elf_abi.h --- defines one additional hash define on top of ./include/elf_mips.h --- not sure what this is used for other than the cygnus_20000828/bfd ./include/elfaccess.h --- provides access macros for the ELF structures. The following header defines a number of special, MIPS, ELF sections for WHIRL, which, although the hash defines all make reference to MIPS, does not seem to require any modification: ./include/sys/elf_whirl.h The following header specifies sections and relocations for the Irix/ia64 and additional Intel ia64: ./include/sys/ia64/elf.h --- specify sections, relocations for Irix/ia64 and Intel specific It is clear that if we are to produce ELF object modules compatable with a version of ld, then this file must be ported to detail the required definitions. A number of the hash defines used in the above headers appear in the more generic header: ./linux/include/elf.h In particular, *_IRIX_* definitons. Currently this file does not contain definitions for our architecture, although we do have an ELF number and so on, and it is not clear how much work it would be ammend this file as required. ./ipa/local/ipl_elfsym.h --- convert WHIRL global symbol table to Elf. plus a number that appear under the GCC and G++ front-ends, which do not seem important to this discussion as they are used to produce parse trees and not RTL, etc. So with the ELF references mapped out is it possible to build the Pro64 compiler to produce only assembler? thanks for any advice on this matter. ben. From owner-pro64-contrib@oss.sgi.com Tue Jun 12 10:06:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5CH6PF31079 for pro64-contrib-outgoing; Tue, 12 Jun 2001 10:06:25 -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 f5CH6MV31076 for ; Tue, 12 Jun 2001 10:06:22 -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 RAA25577; Tue, 12 Jun 2001 17:06:02 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, 12 Jun 2001 17:06:02 0000 (GMT) Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Jun 2001 10:06:01 -0700 Message-ID: <9287DC1579B0D411AA2F009027F44C3F042DFB85@FMSMSX41> From: "Chan, Sun C" To: "'Benedict R. Gaster'" , Pro64 Contrib Subject: RE: ELF binaries when only wishing to produce assembler code... Date: Tue, 12 Jun 2001 10:05:59 -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-contrib@oss.sgi.com Precedence: bulk Currently, Pro64 only output .s files. It does not generate elf object at all. If you want elf object, then you have to do something to make that happen. The compiler used to generate elf object directly, but has been changed to conform to gcc's convention. I doubt if direct object generation works anymore. One needs to be careful with -IPA though. The IR from IPA phase is disguised as ELF objects. If you don't care about IPA, you don't need to worry about it. Otherwise, you just have to define your own 32 bit format (that should be a no brainer, the compiler used to produce both 64bit and 32 bit code under a switch) so that IPA can put it out and read it back properly. I believe the code is done in the so call "gatherer". I.e. first phase of a traditional linker. Sun > -----Original Message----- > From: Benedict R. Gaster [mailto:benedict.gaster@st.com] > Sent: Tuesday, June 12, 2001 3:33 AM > To: Pro64 Contrib > Subject: ELF binaries when only wishing to produce assembler code... > > > Hello! > > I am currently involved in looking at the process of porting > the Pro64 to > new 32bit architecture and have some difficulty in completly > understanding > the ELF requirements. The problem is that we are only interested in > producing assembler suitable for input into a version of GAS > and not with > producing object modules directly. However, it is by no means > clear if a > Pro64 compiler can be built to target the assembler only. > > There are a number of header files releated to ELF: > > ./common/com/config_elf_targ.h --- prototypes API for > target/machine ELF > configuration. > ./common/com/em_elf.h --- prototypes API for > writing ELF module. > > Corresponding C++ source files are provided in: > > ./common/com/ia64/config_elf_targ.cxx > ./common/com/ia64/targ_em_elf.cxx > > which provide, ia64, implementations of the specified ELF > APIs. These two > files files, along with an additional header also defined in > common/com/ia64, are straightforward to implement for a new > architecture. > > The following header defines some C++ typedefs used to > instantiate templates > that are based on the format of an Elf object and requires no porting: > > ./common/com/ir_elf.h > > ./include/cmplrs/elf_interfaces.h --- provides a consumer API to the > .MIPS.interfaces ELF section > ./include/elf_abi.h --- defines one additional > hash define on > top of > ./include/elf_mips.h --- not sure what this is > used for other > than the cygnus_20000828/bfd > ./include/elfaccess.h --- provides access macros for the ELF > structures. > > The following header defines a number of special, MIPS, ELF > sections for > WHIRL, which, although the hash defines all make reference to > MIPS, does not > seem to require any modification: > > ./include/sys/elf_whirl.h > > The following header specifies sections and relocations for > the Irix/ia64 > and additional Intel ia64: > > ./include/sys/ia64/elf.h --- specify sections, relocations > for Irix/ia64 and > Intel specific > > It is clear that if we are to produce ELF object modules > compatable with a > version of ld, then this file must be ported to detail the required > definitions. > > A number of the hash defines used in the above headers appear > in the more > generic header: > > ./linux/include/elf.h > > In particular, *_IRIX_* definitons. Currently this file does > not contain > definitions for our architecture, although we do have an ELF > number and so > on, and it is not clear how much work it would be ammend this file as > required. > > ./ipa/local/ipl_elfsym.h --- convert WHIRL global symbol > table to Elf. > > plus a number that appear under the GCC and G++ front-ends, > which do not > seem important to this discussion as they are used to produce > parse trees > and not RTL, etc. > > So with the ELF references mapped out is it possible to build > the Pro64 > compiler to produce only assembler? > > thanks for any advice on this matter. > > ben. > > From owner-pro64-contrib@oss.sgi.com Tue Jun 12 14:04:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5CL4PN00917 for pro64-contrib-outgoing; Tue, 12 Jun 2001 14:04:25 -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 f5CL4OP00910 for ; Tue, 12 Jun 2001 14:04:24 -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 OAA06876 for ; Tue, 12 Jun 2001 14:04:19 -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 NAA46238; Tue, 12 Jun 2001 13:59:28 -0700 (PDT) Date: Tue, 12 Jun 2001 13:59:28 -0700 (PDT) From: mpm@rohi.engr.sgi.com (Michael Murphy) Message-Id: <200106122059.NAA46238@rohi.engr.sgi.com> To: Pro64 Contrib , "'Benedict R. Gaster'" , "Chan, Sun C" Subject: RE: ELF binaries when only wishing to produce assembler code... Sender: owner-pro64-contrib@oss.sgi.com Precedence: bulk Sun is correct that pro64 generates assembly code for ia64, so it should be relatively straightforward to do that for another architecture. But just to clarify, it is possible to still generate elf directly; we do this internally for mips elf (however we don't open-source all the files involved in the mips target). -- 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-contrib@oss.sgi.com Tue Jun 12 17:07:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5D07Rx30739 for pro64-contrib-outgoing; Tue, 12 Jun 2001 17:07:27 -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-contrib@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-contrib@oss.sgi.com Wed Jun 20 07:36:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5KEaF132698 for pro64-contrib-outgoing; Wed, 20 Jun 2001 07:36:15 -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 f5KEaDV32691 for ; Wed, 20 Jun 2001 07:36:13 -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 CE98448E3 for ; Wed, 20 Jun 2001 14:36:06 +0000 (GMT) Received: by zeta.dmz-eu.st.com (STMicroelectronics, from userid 0) id E70204A61; Wed, 20 Jun 2001 14:36:09 +0000 (GMT) Received: from thistle.bri.st.com (localhost [127.0.0.1]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 7B4EF184E for ; Wed, 20 Jun 2001 14:36:09 +0000 (GMT) Received: from [164.129.14.93] (helo=HARPO) by thistle.bristol.st.com with smtp (Exim 3.03 #5) id 15Cj5R-0006yF-00; Wed, 20 Jun 2001 15:36:05 +0100 From: "Benedict R. Gaster" To: "Pro64 Contrib" , "Benedict. Gaster@St. Com" Subject: Question concerning function calls and pointers in Whirl Date: Wed, 20 Jun 2001 15:41:27 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-pro64-contrib@oss.sgi.com Precedence: bulk Hello! Consider a target with the following byte sizes for C base types: sizeof(int) = sizeof(long) = sizeof(char *) = 4 sizeof(long long) = 64 These target requirements are expressed and implemented in ./gccfe/gnu/config/TARGET/target.h: ... #define BITS_PER_UNIT 8 #define BITS_PER_WORD 32 #define UNITS_PER_WORD 4 #define POINTER_SIZE 32 #define INT_TYPE_SIZE 32 #define LONG_TYPE_SIZE 32 #define LONG_LONG_TYPE_SIZE 64 #define CHAR_TYPE_SIZE 8 ... and ./common/com/TARGET/config_targ.[h|cxx]: ... Pointer_Size = 4; Pointer_Mtype = WHIRL_Mtype_A_On ? MTYPE_A4 : MTYPE_U4; Pointer_type = Pointer_Mtype; Pointer_Mtype2 = MTYPE_U4; Pointer_type2 = MTYPE_U4; ... So compiling the following simple program: int printf(char *, ...); int main(void) { printf("Hello World\n"); return 0; } we might expect to get the following Whirl output: LOC 0 0 source files: 1 "/home/afra/users/benedict/dev/pro64/hello.c" LOC 1 3 int main(void) LOC 1 4 { FUNC_ENTRY <1,20,main> BODY BLOCK END_BLOCK BLOCK END_BLOCK BLOCK PRAGMA 0 120 0 (0x0) # PREAMBLE_END LOC 1 5 printf("Hello World\n"); U4LDA 0 <1,22,(13_bytes)_"Hello_World\n\000"> T<31,anon_ptr.,4> U4PARM 2 T<28,anon_ptr.,4> # by_value VCALL 126 <1,21,printf> # flags 0x7e LOC 1 6 LOC 1 7 return 0; I4INTCONST 0 (0x0) I4RETURN_VAL END_BLOCK however the actual output we currently get is: LOC 0 0 source files: 1 "/home/afra/users/benedict/dev/pro64/hello.c" LOC 1 3 int main(void) LOC 1 4 { FUNC_ENTRY <1,20,main> BODY BLOCK END_BLOCK BLOCK END_BLOCK BLOCK PRAGMA 0 120 0 (0x0) # PREAMBLE_END LOC 1 5 printf("Hello World\n"); U4LDA 0 <1,22,(13_bytes)_"Hello_World\n\000"> T<31,anon_ptr.,4> U4PARM 2 T<28,anon_ptr.,8> # by_value *!!!!**** this has changed to 8 ****!!!!* VCALL 126 <1,21,printf> # flags 0x7e LOC 1 6 LOC 1 7 return 0; I4INTCONST 0 (0x0) I4RETURN_VAL END_BLOCK Here here the argument to the Whirl node VCALL is still U4PARM, as expected, but its type now has a size of 8 bytes, rather than 4! This seems to only happen when passing pointers to a function and not when passing unsigned integers, for example, as can be seen in the following: int bar(unsigned int); ... bar(x); ... which gives: ... U4U4LDID 0 <2,1,x> T<8,.predef_U4,4> U4PARM 2 T<8,.predef_U4,4> # by_value VCALL 126 <1,21,bar> # flags 0x7e ... Have we just missed something silly or something more nasty? thanks for any help, ben. From owner-pro64-contrib@oss.sgi.com Wed Jun 20 08:02:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5KF2ma03942 for pro64-contrib-outgoing; Wed, 20 Jun 2001 08:02:48 -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 f5KF2kV03938 for ; Wed, 20 Jun 2001 08:02:47 -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 A53AB48F6 for ; Wed, 20 Jun 2001 15:02:40 +0000 (GMT) Received: by zeta.dmz-eu.st.com (STMicroelectronics, from userid 0) id BDA4A4AEA; Wed, 20 Jun 2001 15:02:43 +0000 (GMT) Received: from thistle.bri.st.com (localhost [127.0.0.1]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 57ECA184E for ; Wed, 20 Jun 2001 15:02:43 +0000 (GMT) Received: from [164.129.14.93] (helo=HARPO) by thistle.bristol.st.com with smtp (Exim 3.03 #5) id 15CjV9-0007km-00; Wed, 20 Jun 2001 16:02:39 +0100 From: "Benedict R. Gaster" To: , Subject: RE: Question concerning function calls and pointers in Whirl Date: Wed, 20 Jun 2001 16:08:01 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-pro64-contrib@oss.sgi.com Precedence: bulk > Here here the argument to the Whirl node VCALL is still U4PARM, as expected, > but its type now has a size of 8 bytes, rather than 4! I think it should have read "alignment" not "size", as looking in the symbol table (-st) this seems to be the difference. Does this mean that function arguments are getting 8 byte aligned? If so is it possible to stop this? thanks for any help, ben. From owner-pro64-contrib@oss.sgi.com Wed Jun 20 13:43:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5KKhxk17819 for pro64-contrib-outgoing; Wed, 20 Jun 2001 13:43:59 -0700 Received: from hebe.or.intel.com (jffdns02.or.intel.com [134.134.248.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5KKhxV17808 for ; Wed, 20 Jun 2001 13:43:59 -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.40 2001/06/06 21:14:49 root Exp $) with SMTP id UAA03129; Wed, 20 Jun 2001 20:43:50 GMT Received: from orsmsx29.jf.intel.com ([192.168.70.29]) by 192.168.70.200 (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 20 Jun 2001 20:43:50 0000 (GMT) Received: by orsmsx29.jf.intel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Jun 2001 13:43:49 -0700 Message-ID: <9287DC1579B0D411AA2F009027F44C3F0ABD0530@FMSMSX41> From: "Chan, Sun C" To: "'Benedict R. Gaster'" , pro64-contrib@oss.sgi.com Subject: RE: Question concerning function calls and pointers in Whirl Date: Wed, 20 Jun 2001 13:43:44 -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-contrib@oss.sgi.com Precedence: bulk > -----Original Message----- > From: Benedict R. Gaster [mailto:benedict.gaster@st.com] > Sent: Wednesday, June 20, 2001 8:08 AM > To: benedict.gaster@st.com; pro64-contrib@oss.sgi.com > Subject: RE: Question concerning function calls and pointers in Whirl > > > > > > Here here the argument to the Whirl node VCALL is still U4PARM, as > expected, > > but its type now has a size of 8 bytes, rather than 4! > > I think it should have read "alignment" not "size", as > looking in the symbol > table (-st) this seems to be the difference. Does this mean > that function > arguments are getting 8 byte aligned? If so is it possible to > stop this? > This is part of the ABI. Besides, even if you do that, you need to be careful about doubles as parameters. if you ended up with two kinds of alignments, you'll find yourself with a lot of unnecessary complexity and bugs. Think about vararg also. From owner-pro64-contrib@oss.sgi.com Tue Jun 26 09:27:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5QGRNw00530 for pro64-contrib-outgoing; Tue, 26 Jun 2001 09:27:23 -0700 Received: from cs.rpi.edu (mumble.cs.rpi.edu [128.213.8.16]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5QGRMV00527 for ; Tue, 26 Jun 2001 09:27:22 -0700 Received: from contraption (lally-02.cs.rpi.edu [128.113.96.54]) by cs.rpi.edu (8.9.3/8.9.3) with SMTP id MAA80953 for ; Tue, 26 Jun 2001 12:27:20 -0400 (EDT) Message-ID: <003301c0fe5c$fa85e860$6501a8c0@cs.rpi.edu> From: "Sibylle Schupp" To: Subject: GCC-3.0 as front end for Pro64? Date: Tue, 26 Jun 2001 12:28:05 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-pro64-contrib@oss.sgi.com Precedence: bulk Are there any plans to support GCC-3.0 as front end or is anyone else on this mailing list working on the required mapping from TREE to Whirl? Sibylle schupp@cs.rpi.edu