From clattner at apple.com Tue May 1 12:50:26 2007 From: clattner at apple.com (Chris Lattner) Date: Tue, 1 May 2007 10:50:26 -0700 Subject: [LLVMdev] LLVM-related job opportunity at Apple Message-ID: Hi All, We are looking for excellent compiler backend (code generation) engineers. If you are interested, please contact me: http://jobs.apple.com/index.ajs? BID=1&method=mExternal.showJob&RID=7400&CurrentPage=1 Req #2970693 -Chris From tonic at nondot.org Tue May 1 17:30:16 2007 From: tonic at nondot.org (Tanya M. Lattner) Date: Tue, 1 May 2007 15:30:16 -0700 (PDT) Subject: [LLVMdev] NewNightlyTest.pl - Please update Message-ID: I've made some modifications to the NewNightlyTest.pl script and I'm noticing many testers do not seem to update this script (judging from the data being submitted to our database). Please update the script manually, or modify you cron (or whatever you have controlling your tester) to automatically update the testing script before running the tests. Thanks, Tanya From Alireza.Moshtaghi at microchip.com Tue May 1 17:52:35 2007 From: Alireza.Moshtaghi at microchip.com (Alireza.Moshtaghi at microchip.com) Date: Tue, 1 May 2007 15:52:35 -0700 Subject: [LLVMdev] Attending Developers' Meeting Message-ID: Hi I would like to attend the meeting Thanks Alireza Moshtaghi Sr Software Eng, Development Systems, Language Tools group Microchip Technology -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20070501/6337a585/attachment.html From kaushik at rice.edu Tue May 1 20:19:55 2007 From: kaushik at rice.edu (Kaushik Kumar) Date: Tue, 1 May 2007 20:19:55 -0500 Subject: [LLVMdev] Instruction Scheduling in LLVM Message-ID: <017101c78c57$fe70d7c0$12d92a80@Kaushik> Hello, I am working with the SelectionDAG/ScheduleDAG framework to implement a variation of the List scheduling Algorithm in LLVM. I was trying to understand the existing List scheduler implementation in LLVM. I have a doubt about the SUnits structure which contain flagged nodes together. The instructions within a Sunit are scheduled as a single unit. My understanding is that the nodes in the original DAG fall into exactly one of the Sunits. So, I was wondering if the instructions (SDNodes) within a SUnit need to be scheduled seperately? For example, it may be necessary to insert a No-op between the instructions (within one SUnit) in certain cases. Or is the nodes which are flagged together (apart from the main node) are psuedo ops which don't need to be actually emitted? A general overview will also be helpful. (The documentation does not provide much details and the source is too complicated to understand at times). Thank you -Kaushik -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20070501/94d2c626/attachment.html From rspencer at reidspencer.com Tue May 1 20:43:19 2007 From: rspencer at reidspencer.com (Reid Spencer) Date: Tue, 01 May 2007 21:43:19 -0400 Subject: [LLVMdev] Attending Developers' Meeting In-Reply-To: References: Message-ID: Hi Alireza, I've added you to the list. Look forward to meeting you. Reid. On Tue, 1 May 2007 15:52:35 -0700 wrote: >Hi > >I would like to attend the meeting > > > >Thanks > >Alireza Moshtaghi > >Sr Software Eng, Development Systems, Language Tools group > >Microchip Technology > From samah at cs.rice.edu Tue May 1 20:58:25 2007 From: samah at cs.rice.edu (Samah Mahmeed) Date: Tue, 01 May 2007 20:58:25 -0500 Subject: [LLVMdev] LLVM-gcc scheduler Message-ID: <4637F041.40303@cs.rice.edu> I'm a taking a compiler course and I'm supposed to implement a scheduler for the LLVM compiler and comapre its persformance to the existing one used by LLVM-gcc. I need some help understanding what is really happening in LLVM-gcc. In CodeGen/SelectionDAG/ I can see four different Schedulers, which one is used by LLVM? Can you give a hint on where/how to add a new scheduler and test it? or a hint on something that you need to be tried/improved in your scheduler? From samah at cs.rice.edu Tue May 1 20:59:25 2007 From: samah at cs.rice.edu (Samah Mahmeed) Date: Tue, 01 May 2007 20:59:25 -0500 Subject: [LLVMdev] LLVM-gcc scheduler In-Reply-To: <4637F041.40303@cs.rice.edu> References: <4637F041.40303@cs.rice.edu> Message-ID: <4637F07D.6080903@cs.rice.edu> Hello, > I'm a taking a compiler course and I'm supposed to implement a > scheduler for the LLVM compiler and comapre its persformance to the > existing one used by LLVM-gcc. I need some help understanding what is > really happening in LLVM-gcc. In CodeGen/SelectionDAG/ I can see four > different Schedulers, which one is used by LLVM? Can you give a hint > on where/how to add a new scheduler and test it? or a hint on > something that you need to be tried/improved in your scheduler? > Best, Samah From evan.cheng at apple.com Wed May 2 12:41:36 2007 From: evan.cheng at apple.com (Evan Cheng) Date: Wed, 2 May 2007 10:41:36 -0700 Subject: [LLVMdev] LLVM-gcc scheduler In-Reply-To: <4637F041.40303@cs.rice.edu> References: <4637F041.40303@cs.rice.edu> Message-ID: <1B3F2986-8305-4CCE-8E50-0009CA1E888F@apple.com> Currently the default scheduler for ARM / X86 is the bottom up register pressure reduction list scheduler. For others it's top down list scheduler (optimize for latency). See X86ISelLowering.cpp: the setSchedulingPreference() call changes the default. The other schedulers probably have suffered from bit rot but you can still choose them explicitly from llc with -sched=<> options. See llc --help. Take a look at ScheduleDAGSimple.cpp as an example to register a scheduler. Look for RegisterScheduler. If you are ambitious, you can think about a post-register allocation scheduler. :-) It's something on my todo list for a while. There are tons of different scheduling techniques / heurisitics out there. If you find something you would like to attempt, please point us to it. I am sure you will receive lots of feedbacks from the community. Evan On May 1, 2007, at 6:58 PM, Samah Mahmeed wrote: > I'm a taking a compiler course and I'm supposed to implement a > scheduler > for the LLVM compiler and comapre its persformance to the existing one > used by LLVM-gcc. I need some help understanding what is really > happening in LLVM-gcc. In CodeGen/SelectionDAG/ I can see four > different > Schedulers, which one is used by LLVM? Can you give a hint on where/ > how > to add a new scheduler and test it? or a hint on something that you > need > to be tried/improved in your scheduler? > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From evan.cheng at apple.com Wed May 2 12:49:51 2007 From: evan.cheng at apple.com (Evan Cheng) Date: Wed, 2 May 2007 10:49:51 -0700 Subject: [LLVMdev] Instruction Scheduling in LLVM In-Reply-To: <017101c78c57$fe70d7c0$12d92a80@Kaushik> References: <017101c78c57$fe70d7c0$12d92a80@Kaushik> Message-ID: <4EBAE509-509E-46B7-ACF4-4CEB098F010A@apple.com> Some isel nodes produce MVT::Flag value because it has to scheduled right before its use (one use per flag value). An example of this is a compare and a conditional branch (only because we do not model condition code as a register right now). The scheduler is honoring the request by treating a chain of flagged nodes as a single scheduling unit. Evan On May 1, 2007, at 6:19 PM, Kaushik Kumar wrote: > Hello, > > I am working with the SelectionDAG/ScheduleDAG framework to > implement a variation of the List scheduling Algorithm in LLVM. > I was trying to understand the existing List scheduler > implementation in LLVM. I have a doubt about the SUnits structure > which contain flagged nodes together. The instructions within a > Sunit are scheduled as a single unit. My understanding is that the > nodes in the original DAG fall into exactly one of the Sunits. So, > I was wondering if the instructions (SDNodes) within a SUnit need > to be scheduled seperately? For example, it may be necessary to > insert a No-op between the instructions (within one SUnit) in > certain cases. Or is the nodes which are flagged together (apart > from the main node) are psuedo ops which don't need to be actually > emitted? > A general overview will also be helpful. > (The documentation does not provide much details and the source is > too complicated to understand at times). > > Thank you > -Kaushik > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20070502/7c7e7d98/attachment.html From asl at math.spbu.ru Wed May 2 16:37:02 2007 From: asl at math.spbu.ru (Anton Korobeynikov) Date: Thu, 03 May 2007 01:37:02 +0400 Subject: [LLVMdev] [LLVMbugs] Anyone seeing this? In-Reply-To: <16e5fdf90705021417q1a4b70f2pd24715f407ab34a.SS3211SS@mail.gmail.com> References: <16e5fdf90705021417q1a4b70f2pd24715f407ab34a.SS3211SS@mail.gmail.com> Message-ID: <1178141822.29965.23.camel@asl.dorms.spbu.ru> > Anyone seeing this failure? > > FAIL: /Volumes/Gir/devel/llvm/llvm.src/test/CodeGen/Generic/2007-04-14-EHSelectorCrash.ll > for PR1326 Seems it was due to my changes. Investigating. -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University. From isanbard at gmail.com Wed May 2 16:40:05 2007 From: isanbard at gmail.com (Bill) Date: Wed, 2 May 2007 14:40:05 -0700 Subject: [LLVMdev] [LLVMbugs] Anyone seeing this? In-Reply-To: <1178141822.29965.23.camel@asl.dorms.spbu.ru> References: <16e5fdf90705021417q1a4b70f2pd24715f407ab34a.SS3211SS@mail.gmail.com> <1178141822.29965.23.camel@asl.dorms.spbu.ru> Message-ID: <16e5fdf90705021440h34582816n787df35294abf016@mail.gmail.com> Thanks :-) -bw On 5/2/07, Anton Korobeynikov wrote: > > Anyone seeing this failure? > > > > FAIL: /Volumes/Gir/devel/llvm/llvm.src/test/CodeGen/Generic/2007-04-14-EHSelectorCrash.ll > > for PR1326 > Seems it was due to my changes. Investigating. > > > -- > With best regards, Anton Korobeynikov. > > Faculty of Mathematics & Mechanics, Saint Petersburg State University. > > > From wilsonk at cpsc.ucalgary.ca Thu May 3 02:07:11 2007 From: wilsonk at cpsc.ucalgary.ca (wilsonk at cpsc.ucalgary.ca) Date: Thu, 3 May 2007 01:07:11 -0600 (MDT) Subject: [LLVMdev] Attending conference - possibly Message-ID: <60727.68.144.176.248.1178176031.squirrel@webmail.cpsc.ucalgary.ca> Hi everyone, I would like to attend the conference, but may not be able to make it for sure. Could you put me down as unconfirmed, please. Thanks, Kelly Wilson, M.Sc. Independant University of Calgary Alumnus From rspencer at reidspencer.com Thu May 3 06:17:08 2007 From: rspencer at reidspencer.com (Reid Spencer) Date: Thu, 03 May 2007 07:17:08 -0400 Subject: [LLVMdev] Attending conference - possibly In-Reply-To: <60727.68.144.176.248.1178176031.squirrel@webmail.cpsc.ucalgary.ca> References: <60727.68.144.176.248.1178176031.squirrel@webmail.cpsc.ucalgary.ca> Message-ID: Hi Kelly, On Thu, 3 May 2007 01:07:11 -0600 (MDT) wilsonk at cpsc.ucalgary.ca wrote: >Hi everyone, > >I would like to attend the conference, but may not be able to make it for >sure. Could you put me down as unconfirmed, please. I've put you on the unconfirmed list. Hope you can make it. Reid. > >Thanks, >Kelly Wilson, M.Sc. >Independant >University of Calgary Alumnus > > >_______________________________________________ >LLVM Developers mailing list >LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From basile at starynkevitch.net Thu May 3 09:38:59 2007 From: basile at starynkevitch.net (Basile STARYNKEVITCH) Date: Thu, 3 May 2007 16:38:59 +0200 Subject: [LLVMdev] which g++ to compile LLVM CVS on Linux/AMD64? Message-ID: <20070503143859.GA31755@ours.starynkevitch.net> Hello All, What version of g++ is usable to compile the latest LLVM CVS snapshot on a Linux/x86-64 (AMD64) Debian/ Sid or Etch plateform? What compiler do LLVM dzevelopers use to compile LLVM on Linux/X86-64 systems? IKt seems that most versions of g++ fail to compile LLVM and that some others compile it wrongly (producing buggy code)? Why can't g++-4.1 be used? FWIW, the latest gcc snapshot from yesterday gcc version 4.3.0 20070501 (experimental) fail to compile latest LLVM (with compile errors!). Is LLVM bootstraped thru g++-llvm? Regards -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basilestarynkevitchnet mobile: +33 6 8501 2359 8, rue de la Fa?encerie, 92340 Bourg La Reine, France *** opinions {are only mines, sont seulement les miennes} *** From andrewl at lenharth.org Thu May 3 10:41:54 2007 From: andrewl at lenharth.org (Andrew Lenharth) Date: Thu, 3 May 2007 10:41:54 -0500 Subject: [LLVMdev] which g++ to compile LLVM CVS on Linux/AMD64? In-Reply-To: <20070503143859.GA31755@ours.starynkevitch.net> References: <20070503143859.GA31755@ours.starynkevitch.net> Message-ID: <85dfcd7f0705030841y5de44761j6cb2b9e0e0188d6c@mail.gmail.com> On 5/3/07, Basile STARYNKEVITCH wrote: > > Hello All, > > What version of g++ is usable to compile the latest LLVM CVS snapshot on a > Linux/x86-64 (AMD64) Debian/ Sid or Etch plateform? I am using gcc version 4.1.2 on debian testing without problem. Andrew From sabre at nondot.org Thu May 3 11:36:22 2007 From: sabre at nondot.org (Chris Lattner) Date: Thu, 3 May 2007 09:36:22 -0700 (PDT) Subject: [LLVMdev] which g++ to compile LLVM CVS on Linux/AMD64? In-Reply-To: <20070503143859.GA31755@ours.starynkevitch.net> References: <20070503143859.GA31755@ours.starynkevitch.net> Message-ID: On Thu, 3 May 2007, Basile STARYNKEVITCH wrote: > > What version of g++ is usable to compile the latest LLVM CVS snapshot on a > Linux/x86-64 (AMD64) Debian/ Sid or Etch plateform? Please look here: http://llvm.org/docs/GettingStarted.html#brokengcc I'd suggest late versions of GCC 4.0.x. The 4.1 series has had numerous problems compiling LLVM on x86-64, though some people have had success with some vendor versions. > FWIW, the latest gcc snapshot from yesterday gcc version 4.3.0 20070501 > (experimental) fail to compile latest LLVM (with compile errors!). Please file an llvm bug report with these errors. It may be that we are doing something illegal in C++ that is only now getting caught. If the source is valid and G++ is incorrectly complaining, please file a bug against GCC. > Is LLVM bootstraped thru g++-llvm? Yes, it can be, and it works. -Chris -- http://nondot.org/sabre/ http://llvm.org/ From basile at starynkevitch.net Thu May 3 11:41:52 2007 From: basile at starynkevitch.net (Basile STARYNKEVITCH) Date: Thu, 3 May 2007 18:41:52 +0200 Subject: [LLVMdev] which g++ to compile LLVM CVS on Linux/AMD64? In-Reply-To: References: <20070503143859.GA31755@ours.starynkevitch.net> Message-ID: <20070503164152.GA2563@ours.starynkevitch.net> Le Thu, May 03, 2007 at 09:36:22AM -0700, Chris Lattner ?crivait/wrote: > On Thu, 3 May 2007, Basile STARYNKEVITCH wrote: > > > > > FWIW, the latest gcc snapshot from yesterday gcc version 4.3.0 20070501 > > (experimental) fail to compile latest LLVM (with compile errors!). > > Please file an llvm bug report with these errors. It may be that we are > doing something illegal in C++ that is only now getting caught. If the > source is valid and G++ is incorrectly complaining, please file a bug > against GCC. > I'm sorry to reply on the list (but I failed even waiting 15 minutes to get a mailed password from the LLVM bugzilla system). With the latest CVS and with ./configure CXX=g++-snap where g++-snap is yesterday's GCC trunk : g++-snap -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../configure --disable-multilib --program-suffix=-snap --enable-languages=c,c++ Thread model: posix gcc version 4.3.0 20070501 (experimental) I am getting the following errors llvm[1]: Building Debug Archive Library libLLVMSystem.a make[1]: Leaving directory `/usr/src/Lang/llvm/lib/System' make[1]: Entering directory `/usr/src/Lang/llvm/lib/Support' llvm[1]: Compiling APInt.cpp for Debug build In file included from /usr/src/Lang/llvm/include/llvm/Type.h:14, from /usr/src/Lang/llvm/include/llvm/DerivedTypes.h:21, from APInt.cpp:17: /usr/src/Lang/llvm/include/llvm/AbstractTypeUser.h:19:51: error: missing terminating ' character In file included from APInt.cpp:16: /usr/src/Lang/llvm/include/llvm/ADT/APInt.h:1041: warning: type qualifiers ignored on function return type /usr/src/Lang/llvm/include/llvm/ADT/APInt.h:1047: warning: type qualifiers ignored on function return type In file included from APInt.cpp:17: /usr/src/Lang/llvm/include/llvm/DerivedTypes.h: In member function 'virtual void llvm::OpaqueType::refineAbstractType(const llvm::DerivedType*, const llvm::Type*)': /usr/src/Lang/llvm/include/llvm/DerivedTypes.h:412: error: 'abort' was not declared in this scope /usr/src/Lang/llvm/include/llvm/DerivedTypes.h: In member function 'virtual void llvm::OpaqueType::typeBecameConcrete(const llvm::DerivedType*)': /usr/src/Lang/llvm/include/llvm/DerivedTypes.h:415: error: 'abort' was not declared in this scope Hope that this could help someone. I really don't know if it is a bug in GCC (tuesday's SVN snapshot) or in LLVM (today's CVS snapshot) Regards. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basilestarynkevitchnet mobile: +33 6 8501 2359 8, rue de la Fa?encerie, 92340 Bourg La Reine, France *** opinions {are only mines, sont seulement les miennes} *** From rspencer at reidspencer.com Thu May 3 13:28:09 2007 From: rspencer at reidspencer.com (Reid Spencer) Date: Thu, 03 May 2007 14:28:09 -0400 Subject: [LLVMdev] which g++ to compile LLVM CVS on Linux/AMD64? In-Reply-To: <20070503164152.GA2563@ours.starynkevitch.net> References: <20070503143859.GA31755@ours.starynkevitch.net> <20070503164152.GA2563@ours.starynkevitch.net> Message-ID: Basile, On Thu, 3 May 2007 18:41:52 +0200 Basile STARYNKEVITCH wrote: >Le Thu, May 03, 2007 at 09:36:22AM -0700, Chris Lattner ?crivait/wrote: >> On Thu, 3 May 2007, Basile STARYNKEVITCH wrote: >> > >> >> > FWIW, the latest gcc snapshot from yesterday gcc version 4.3.0 20070501 >> > (experimental) fail to compile latest LLVM (with compile errors!). >> >> Please file an llvm bug report with these errors. It may be that we are >> doing something illegal in C++ that is only now getting caught. If the >> source is valid and G++ is incorrectly complaining, please file a bug >> against GCC. >> > >I'm sorry to reply on the list (but I failed even waiting 15 minutes to get >a mailed password from the LLVM bugzilla system). > > >With the latest CVS and with ./configure CXX=g++-snap where >g++-snap is yesterday's GCC trunk : >g++-snap -v >Using built-in specs. >Target: x86_64-unknown-linux-gnu >Configured with: ../configure --disable-multilib --program-suffix=-snap --enable-languages=c,c++ >Thread model: posix >gcc version 4.3.0 20070501 (experimental) > >I am getting the following errors > >llvm[1]: Building Debug Archive Library libLLVMSystem.a >make[1]: Leaving directory `/usr/src/Lang/llvm/lib/System' >make[1]: Entering directory `/usr/src/Lang/llvm/lib/Support' >llvm[1]: Compiling APInt.cpp for Debug build >In file included from /usr/src/Lang/llvm/include/llvm/Type.h:14, > from /usr/src/Lang/llvm/include/llvm/DerivedTypes.h:21, > from APInt.cpp:17: >/usr/src/Lang/llvm/include/llvm/AbstractTypeUser.h:19:51: error: missing terminating ' character This is likely a bug in gcc. Its not liking ' in a #error pragma .. go figure. I fixed this by removing the ' >In file included from APInt.cpp:16: >/usr/src/Lang/llvm/include/llvm/ADT/APInt.h:1041: warning: type qualifiers ignored on function return type >/usr/src/Lang/llvm/include/llvm/ADT/APInt.h:1047: warning: type qualifiers ignored on function return type These two are bugs in your compiler. >In file included from APInt.cpp:17: >/usr/src/Lang/llvm/include/llvm/DerivedTypes.h: In member function 'virtual void llvm::OpaqueType::refineAbstractType(const llvm::DerivedType*, const llvm::Type*)': >/usr/src/Lang/llvm/include/llvm/DerivedTypes.h:412: error: 'abort' was not declared in this scope This is either a bug in the compiler or a difference in which is included in DerivedTypes.h via AbstractTypeUser.h. >/usr/src/Lang/llvm/include/llvm/DerivedTypes.h: In member function 'virtual void llvm::OpaqueType::typeBecameConcrete(const llvm::DerivedType*)': >/usr/src/Lang/llvm/include/llvm/DerivedTypes.h:415: error: 'abort' was not declared in this scope > > >Hope that this could help someone. I really don't know if it is a bug in GCC >(tuesday's SVN snapshot) or in LLVM (today's CVS snapshot) I would try using a different GCC (4.0.X works well). Reid. > >Regards. >-- >Basile STARYNKEVITCH http://starynkevitch.net/Basile/ >email: basilestarynkevitchnet mobile: +33 6 8501 2359 >8, rue de la Fa?encerie, 92340 Bourg La Reine, France >*** opinions {are only mines, sont seulement les miennes} *** >_______________________________________________ >LLVM Developers mailing list >LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From tomas.evensen at windriver.com Thu May 3 13:30:01 2007 From: tomas.evensen at windriver.com (Evensen, Tomas) Date: Thu, 3 May 2007 11:30:01 -0700 Subject: [LLVMdev] LLVM Developers' meeting Message-ID: <5E858C84F061A447A54EBD364580B3942D2100@ala-mail08.corp.ad.wrs.com> I'd like to attend. Thanks, Tomas Evensen Chief Technology Officer 500 Wind River Way Alameda, CA 94501 510-749-2783 office 510-749-2007 fax www.windriver.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20070503/4687875f/attachment.html From rspencer at reidspencer.com Thu May 3 14:12:21 2007 From: rspencer at reidspencer.com (Reid Spencer) Date: Thu, 03 May 2007 15:12:21 -0400 Subject: [LLVMdev] LLVM Developers' meeting In-Reply-To: <5E858C84F061A447A54EBD364580B3942D2100@ala-mail08.corp.ad.wrs.com> References: <5E858C84F061A447A54EBD364580B3942D2100@ala-mail08.corp.ad.wrs.com> Message-ID: Hi Tomas, On Thu, 3 May 2007 11:30:01 -0700 "Evensen, Tomas" wrote: >I'd like to attend. You're on the list! See you there. Reid. > >Thanks, > >Tomas Evensen > >Chief Technology Officer >500 Wind River Way >Alameda, CA 94501 >510-749-2783 office >510-749-2007 fax >www.windriver.com >/Signatures/www.windriver.com> > > From lakshman at cisco.com Thu May 3 14:56:14 2007 From: lakshman at cisco.com (Lakshmankumar Mukkavilli (lakshman)) Date: Thu, 3 May 2007 12:56:14 -0700 Subject: [LLVMdev] LLVM Developers' meeting In-Reply-To: References: <5E858C84F061A447A54EBD364580B3942D2100@ala-mail08.corp.ad.wrs.com> Message-ID: <7023CD936D1501409946F382B52DD7FA02A1C0A1@xmb-sjc-228.amer.cisco.com> I plan to attend. Lakshmankumar Mukkavilli lakshman at cisco.com Cisco Systems From sabre at nondot.org Thu May 3 22:43:14 2007 From: sabre at nondot.org (Chris Lattner) Date: Thu, 3 May 2007 20:43:14 -0700 (PDT) Subject: [LLVMdev] alias information on machine instructions In-Reply-To: <4635D0D4.40202@mail.tuwien.ac.at> References: <4635D0D4.40202@mail.tuwien.ac.at> Message-ID: On Mon, 30 Apr 2007, Florian Brandner wrote: > i`m working on a machine instruction scheduler for an VLIW architecture. > loads are somewhat expensive on this architecture, thus i would like to > reorder unrelated loads/stores to better hide load latencies. > > to do this, i would need alias information on machine instructions, > i.e., which machine instructions may access the same memory region. > > as far as i know, this is not available at the moment? are there any > plans to get aliasing information on machine instructions? There are a couple of ways to do this. Is your scheduler a prepass scheduler (before regalloc) or a post-pass scheduler (after regalloc)? If you want to extract maximal parallelism, I assume you want a prepass scheduler. In that case, you should look into the SelectionDAG based schedulers, which do have alias information on them. -Chris -- http://nondot.org/sabre/ http://llvm.org/ From fbrandne at mail.tuwien.ac.at Fri May 4 03:29:17 2007 From: fbrandne at mail.tuwien.ac.at (Florian Brandner) Date: Fri, 04 May 2007 10:29:17 +0200 Subject: [LLVMdev] alias information on machine instructions In-Reply-To: References: <4635D0D4.40202@mail.tuwien.ac.at> Message-ID: <463AEEDD.3000106@mail.tuwien.ac.at> Chris Lattner wrote: > There are a couple of ways to do this. Is your scheduler a prepass > scheduler (before regalloc) or a post-pass scheduler (after regalloc)? it is a post-pass scheduler, which operates on MachineInstrs. we need to run it after register allocation to hide latencies of spill code, prolog, and epilog. > If you want to extract maximal parallelism, I assume you want a prepass > scheduler. In that case, you should look into the SelectionDAG based > schedulers, which do have alias information on them. i had a look at the SelectionDAG based schedulers. it seems that aliasing loads/stores are chained together by the DAGCombiner. after scheduling, when the MachineInstrs are created, the alias information cannot be used anymore in the current framework. is this correct? i don't think that it is a good idea to do alias analysis on MachineInstrs, thus i would like to preserve the alias information, and annotate the MachineInstrs explicitly. however, this information might be invalidated by subsequent passes. currently, our backend does not emit any additional loads/stores execpt for spill code, prolog and epilog. thus this approach would work (at least for now). do you have any ideas for a better solution? florian From fbrandne at mail.tuwien.ac.at Fri May 4 07:37:53 2007 From: fbrandne at mail.tuwien.ac.at (Florian Brandner) Date: Fri, 04 May 2007 14:37:53 +0200 Subject: [LLVMdev] llvm-test make problems Message-ID: <463B2921.8040405@mail.tuwien.ac.at> hello, i've problems running the llvm-test suite using debian linux and make 3.81. it works fine on my laptop, running openSuse and make 3.81. i already tried to install make 3.75 and 3.79, both did not work. the error message is: make[1]: *** No rule to make target `Output/sse.expantfft.bc', needed by `Output/sse.expandfft.linked.rbc'. Stop. using make -p, i see that Makefile.singlesrc has the following pattern rule, but it does not match for some reason! Output/%.linked.rbc: Output/%.bc -cp -f $< $@ i played a little with the makefile and found that this rule matches, when i add it to Makefile.singlesrc: Output/sse.expandfft.linked.rbc: Output/sse.expantfft.bc -cp -f $< $@ so it seems that it is a problem with the pattern rule?? on irc anton told me that there was a similar problem on mingw, and that an older make version (3.79) helped there. has anybody else encountered these problems? florian From rspencer at reidspencer.com Fri May 4 08:31:08 2007 From: rspencer at reidspencer.com (Reid Spencer) Date: Fri, 04 May 2007 09:31:08 -0400 Subject: [LLVMdev] llvm-test make problems In-Reply-To: <463B2921.8040405@mail.tuwien.ac.at> References: <463B2921.8040405@mail.tuwien.ac.at> Message-ID: On Fri, 04 May 2007 14:37:53 +0200 Florian Brandner wrote: >hello, > >i've problems running the llvm-test suite using debian linux and make >3.81. it works fine on my laptop, running openSuse and make 3.81. > >i already tried to install make 3.75 and 3.79, both did not work. > >the error message is: > >make[1]: *** No rule to make target `Output/sse.expantfft.bc', needed by >`Output/sse.expandfft.linked.rbc'. Stop. Have you modified the makefile in any way? Note that sse.expantfft.bc should be sse.expandfft.bc > > >using make -p, i see that Makefile.singlesrc has the following pattern >rule, but it does not match for some reason! > >Output/%.linked.rbc: Output/%.bc > -cp -f $< $@ > > >i played a little with the makefile and found that this rule matches, >when i add it to Makefile.singlesrc: > >Output/sse.expandfft.linked.rbc: Output/sse.expantfft.bc > -cp -f $< $@ You've mis-typed sse.expandfft.bc as sse.expantfft.bc > >so it seems that it is a problem with the pattern rule?? Nope, just a typo. Reid. > >on irc anton told me that there was a similar problem on mingw, and that > an older make version (3.79) helped there. has anybody else encountered >these problems? > >florian > > > > >_______________________________________________ >LLVM Developers mailing list >LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From fbrandne at mail.tuwien.ac.at Fri May 4 08:29:24 2007 From: fbrandne at mail.tuwien.ac.at (Florian Brandner) Date: Fri, 04 May 2007 15:29:24 +0200 Subject: [LLVMdev] llvm-test make problems In-Reply-To: References: <463B2921.8040405@mail.tuwien.ac.at> Message-ID: <463B3534.4060806@mail.tuwien.ac.at> Reid Spencer wrote: > Have you modified the makefile in any way? Note that sse.expantfft.bc should be sse.expandfft.bc no, did'nt change it. the typo before seems to be an error while copying from the terminal. i've cleaned everything and tried again. this is the messsage: [brandner:/localtmp/brandner/dev/llvm-test:529] make -j1 TEST=nightly 2>&1 | tee report.nightly.raw.out make[1]: Entering directory `/localtmp/brandner/dev/llvm-test/SingleSource' make[2]: Entering directory `/localtmp/brandner/dev/llvm-test/SingleSource/UnitTests' make[3]: Entering directory `/localtmp/brandner/dev/llvm-test/SingleSource/UnitTests/Vector' make[4]: Entering directory `/localtmp/brandner/dev/llvm-test/SingleSource/UnitTests/Vector/SSE' make[4]: *** No rule to make target `Output/sse.expandfft.linked.rbc', needed by `Output/sse.expandfft.linked.bc'. Stop. make[4]: Leaving directory `/localtmp/brandner/dev/llvm-test/SingleSource/UnitTests/Vector/SSE' make[3]: *** [test] Error 1 make[3]: Leaving directory `/localtmp/brandner/dev/llvm-test/SingleSource/UnitTests/Vector' make[2]: *** [test] Error 1 make[2]: Leaving directory `/localtmp/brandner/dev/llvm-test/SingleSource/UnitTests' make[1]: *** [UnitTests/.maketest] Error 2 make[1]: Leaving directory `/localtmp/brandner/dev/llvm-test/SingleSource' make: *** [SingleSource/.maketest] Error 2 From rspencer at reidspencer.com Fri May 4 08:57:10 2007 From: rspencer at reidspencer.com (Reid Spencer) Date: Fri, 04 May 2007 09:57:10 -0400 Subject: [LLVMdev] llvm-test make problems In-Reply-To: <463B3534.4060806@mail.tuwien.ac.at> References: <463B2921.8040405@mail.tuwien.ac.at> <463B3534.4060806@mail.tuwien.ac.at> Message-ID: Florian, I don't know. This doesn't happen for me. I use make 3.80. The only things I can think of: 1. Is your "opt" tool built? 2. Has the PROGRAMS_TO_TEST make variable been subverted somehow? 3. Do you have strange environment settings that affect make? Reid. On Fri, 04 May 2007 15:29:24 +0200 Florian Brandner wrote: >Reid Spencer wrote: > >> Have you modified the makefile in any way? Note that sse.expantfft.bc should be sse.expandfft.bc > >no, did'nt change it. >the typo before seems to be an error while copying from the terminal. > >i've cleaned everything and tried again. this is the messsage: > >[brandner:/localtmp/brandner/dev/llvm-test:529] make -j1 TEST=nightly >2>&1 | tee report.nightly.raw.out >make[1]: Entering directory `/localtmp/brandner/dev/llvm-test/SingleSource' >make[2]: Entering directory >`/localtmp/brandner/dev/llvm-test/SingleSource/UnitTests' >make[3]: Entering directory >`/localtmp/brandner/dev/llvm-test/SingleSource/UnitTests/Vector' >make[4]: Entering directory >`/localtmp/brandner/dev/llvm-test/SingleSource/UnitTests/Vector/SSE' >make[4]: *** No rule to make target `Output/sse.expandfft.linked.rbc', >needed by `Output/sse.expandfft.linked.bc'. Stop. >make[4]: Leaving directory >`/localtmp/brandner/dev/llvm-test/SingleSource/UnitTests/Vector/SSE' >make[3]: *** [test] Error 1 >make[3]: Leaving directory >`/localtmp/brandner/dev/llvm-test/SingleSource/UnitTests/Vector' >make[2]: *** [test] Error 1 >make[2]: Leaving directory >`/localtmp/brandner/dev/llvm-test/SingleSource/UnitTests' >make[1]: *** [UnitTests/.maketest] Error 2 >make[1]: Leaving directory `/localtmp/brandner/dev/llvm-test/SingleSource' >make: *** [SingleSource/.maketest] Error 2 > > > From greened at obbligato.org Fri May 4 10:53:14 2007 From: greened at obbligato.org (David Greene) Date: Fri, 04 May 2007 10:53:14 -0500 Subject: [LLVMdev] 1 Week Before 2.0 Branch Creation In-Reply-To: References: Message-ID: <463B56EA.5060303@obbligato.org> Tanya M. Lattner wrote: > I'm asking that all platform maintainers and available llvm developers > review the nightly tester results. Please XFAIL any dejagnu tests that are > currently failing, fix any warnings, and review the results of the full > llvm test suite. If a test failure is determined to be something that > needs to be fixed before the release, please fix it or file a bugzilla > bug, and set the target to 2.0. > > Any enhancements scheduled for the 2.0 release should go in ASAP. This > work should be completed before May 7th. Please try to avoid checking > in large changes right before the deadline. I very much want to get my regalloc refactoring changes in but I don't have a consistent platform to test them on. Someone broke llvm-gcc bootstrapping late last week or this week. Can we please freeze features for a while and get some stability in the tree before we branch 2.0? I really need to test these patches and it seems like the tree has been broken every other day for a week. -Dave From sabre at nondot.org Fri May 4 12:17:05 2007 From: sabre at nondot.org (Chris Lattner) Date: Fri, 4 May 2007 10:17:05 -0700 (PDT) Subject: [LLVMdev] llvm-test make problems In-Reply-To: <463B3534.4060806@mail.tuwien.ac.at> References: <463B2921.8040405@mail.tuwien.ac.at> <463B3534.4060806@mail.tuwien.ac.at> Message-ID: On Fri, 4 May 2007, Florian Brandner wrote: > make[1]: Leaving directory `/localtmp/brandner/dev/llvm-test/SingleSource' > make: *** [SingleSource/.maketest] Error 2 Is it just this one test that doesn't work, or do no tests work? If no tests work, you probably need to rerun configure in llvm-test. Make sure that llvm-gcc is in your path and detected by the configure script. -Chris -- http://nondot.org/sabre/ http://llvm.org/ From tonic at nondot.org Fri May 4 12:49:38 2007 From: tonic at nondot.org (Tanya M. Lattner) Date: Fri, 4 May 2007 10:49:38 -0700 (PDT) Subject: [LLVMdev] 1 Week Before 2.0 Branch Creation In-Reply-To: <463B56EA.5060303@obbligato.org> References: <463B56EA.5060303@obbligato.org> Message-ID: > I very much want to get my regalloc refactoring changes in but I don't > have a consistent platform to test them on. Someone broke llvm-gcc > bootstrapping late last week or this week. How large of a change have you made? With 3 days before the branch creation, I strongly advise people not to be checking in major changes. > Can we please freeze features for a while and get some stability in > the tree before we branch 2.0? I really need to test these patches > and it seems like the tree has been broken every other day for a week. This week has been a bit crazy with people checking in their changes for 2.0. When checking in, people are suppose to be running the llvm-test suite and regression tests. Unfortunately, this doesn't always seem to happen and its hard to control. I know its not a great solution, but you can do preliminary tests with the last stable version of cvs that you (or check the test results to find that date). Creating the branch is a way of freezing the code. If the tree isn't stable on Monday, I will have to make a decision on how to proceed (ie. backing out changes). We may need to change our proceedures for releases in the future. This is how we have done it in the past with no problem, but LLVM is growing much more rapidly now. -Tanya From isanbard at gmail.com Fri May 4 13:54:24 2007 From: isanbard at gmail.com (Bill) Date: Fri, 4 May 2007 11:54:24 -0700 Subject: [LLVMdev] LLVM-GCC Source Updated? Message-ID: <16e5fdf90705041154i6b8ab9ddn9d269629f6d77c8f@mail.gmail.com> Hi all, Has anyone gotten the latest/greatest sources from the LLVM-GCC open source server lately? If not, I could make a tarball of the newest one and place it somewhere (any suggestions?) so that people who need the changes for the upcoming feature freeze will have them. Terribly sorry for all of the problems with the source synchronizations... -bw From lefever at crhc.uiuc.edu Fri May 4 14:17:36 2007 From: lefever at crhc.uiuc.edu (Ryan M. Lefever) Date: Fri, 04 May 2007 14:17:36 -0500 Subject: [LLVMdev] makefile commands Message-ID: <463B86D0.3060306@crhc.uiuc.edu> When using the makefiles in LLVM, the commands that Make executes are hidden from the user. Instead something like: llvm[3]: Compiling Reg2Mem.cpp for Debug build is printed to the terminal, rather than the commands that are used to build Reg2Mem.cpp. Is there a way to get the makefiles to print the commands that they are executing? Regards, Ryan From asl at math.spbu.ru Fri May 4 14:17:49 2007 From: asl at math.spbu.ru (Anton Korobeynikov) Date: Fri, 04 May 2007 23:17:49 +0400 Subject: [LLVMdev] LLVM-GCC Source Updated? In-Reply-To: <16e5fdf90705041154i6b8ab9ddn9d269629f6d77c8f.SS536SS@mail.gmail.com> References: <16e5fdf90705041154i6b8ab9ddn9d269629f6d77c8f.SS536SS@mail.gmail.com> Message-ID: <1178306269.13114.28.camel@asl.dorms.spbu.ru> Hello, Bill. > Has anyone gotten the latest/greatest sources from the LLVM-GCC open > source server lately? No. It's still at rev 319 (as of 29.04). -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University. From tonic at nondot.org Fri May 4 15:19:13 2007 From: tonic at nondot.org (Tanya M. Lattner) Date: Fri, 4 May 2007 13:19:13 -0700 (PDT) Subject: [LLVMdev] makefile commands In-Reply-To: <463B86D0.3060306@crhc.uiuc.edu> References: <463B86D0.3060306@crhc.uiuc.edu> Message-ID: > When using the makefiles in LLVM, the commands that Make executes are > hidden from the user. Instead something like: > > llvm[3]: Compiling Reg2Mem.cpp for Debug build > > is printed to the terminal, rather than the commands that are used to > build Reg2Mem.cpp. Is there a way to get the makefiles to print the > commands that they are executing? VERBOSE=1 -Tanya From lefever at crhc.uiuc.edu Fri May 4 14:20:46 2007 From: lefever at crhc.uiuc.edu (Ryan M. Lefever) Date: Fri, 04 May 2007 14:20:46 -0500 Subject: [LLVMdev] makefile commands In-Reply-To: References: <463B86D0.3060306@crhc.uiuc.edu> Message-ID: <463B878E.50200@crhc.uiuc.edu> Thanks! Tanya M. Lattner wrote: >>When using the makefiles in LLVM, the commands that Make executes are >>hidden from the user. Instead something like: >> >>llvm[3]: Compiling Reg2Mem.cpp for Debug build >> >>is printed to the terminal, rather than the commands that are used to >>build Reg2Mem.cpp. Is there a way to get the makefiles to print the >>commands that they are executing? > > > VERBOSE=1 > > -Tanya > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev -- Ryan M. Lefever [http://www.ews.uiuc.edu/~lefever] From isanbard at gmail.com Fri May 4 15:33:36 2007 From: isanbard at gmail.com (Bill) Date: Fri, 4 May 2007 13:33:36 -0700 Subject: [LLVMdev] LLVM-GCC Source Updated? In-Reply-To: <1178306269.13114.28.camel@asl.dorms.spbu.ru> References: <16e5fdf90705041154i6b8ab9ddn9d269629f6d77c8f.SS536SS@mail.gmail.com> <1178306269.13114.28.camel@asl.dorms.spbu.ru> Message-ID: <16e5fdf90705041333l371b6ca3v1aaf51a3de57e9dd@mail.gmail.com> On 5/4/07, Anton Korobeynikov wrote: > Hello, Bill. > > > Has anyone gotten the latest/greatest sources from the LLVM-GCC open > > source server lately? > No. It's still at rev 319 (as of 29.04). > Yeesh...Okay, I'm working with Jeff C. to get a copy of the TOT out to people. I'm also pinging the rsync wonks here to see if there's something amiss. -bw From jeffc at jolt-lang.org Fri May 4 16:43:38 2007 From: jeffc at jolt-lang.org (Jeff Cohen) Date: Fri, 04 May 2007 14:43:38 -0700 Subject: [LLVMdev] LLVM-GCC Source Updated? In-Reply-To: <16e5fdf90705041333l371b6ca3v1aaf51a3de57e9dd@mail.gmail.com> References: <16e5fdf90705041154i6b8ab9ddn9d269629f6d77c8f.SS536SS@mail.gmail.com> <1178306269.13114.28.camel@asl.dorms.spbu.ru> <16e5fdf90705041333l371b6ca3v1aaf51a3de57e9dd@mail.gmail.com> Message-ID: <463BA90A.1090303@jolt-lang.org> The llvm-gcc source can be download from: http://jolt-lang.org/llvm-gcc.tar.bz2 31mb ~7 minute download http://jolt-lang.org/llvm-gcc.tar.gz 40mb ~8.5 minute download Download times assume you are the only person downloading. Please download the bz2 version if possible. I currently have no unexpected failures. Bill wrote: > On 5/4/07, Anton Korobeynikov wrote: > >> Hello, Bill. >> >> >>> Has anyone gotten the latest/greatest sources from the LLVM-GCC open >>> source server lately? >>> >> No. It's still at rev 319 (as of 29.04). >> >> > Yeesh...Okay, I'm working with Jeff C. to get a copy of the TOT out to > people. I'm also pinging the rsync wonks here to see if there's > something amiss. > > -bw > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > From isanbard at gmail.com Fri May 4 17:12:59 2007 From: isanbard at gmail.com (Bill) Date: Fri, 4 May 2007 15:12:59 -0700 Subject: [LLVMdev] LLVM-GCC Source Updated? In-Reply-To: <463BA90A.1090303@jolt-lang.org> References: <16e5fdf90705041154i6b8ab9ddn9d269629f6d77c8f.SS536SS@mail.gmail.com> <1178306269.13114.28.camel@asl.dorms.spbu.ru> <16e5fdf90705041333l371b6ca3v1aaf51a3de57e9dd@mail.gmail.com> <463BA90A.1090303@jolt-lang.org> Message-ID: <16e5fdf90705041512q395da103w1b0eceba5e0865f9@mail.gmail.com> Thank you Jeff! I think I found a problem with the mirror (duh! ;-) ) and am in the process of fixing it. Please use this tarball for now. Cheers! -bw On 5/4/07, Jeff Cohen wrote: > The llvm-gcc source can be download from: > > http://jolt-lang.org/llvm-gcc.tar.bz2 31mb ~7 minute download > http://jolt-lang.org/llvm-gcc.tar.gz 40mb ~8.5 minute download > > Download times assume you are the only person downloading. Please > download the bz2 version if possible. > > I currently have no unexpected failures. > > > Bill wrote: > > On 5/4/07, Anton Korobeynikov wrote: > > > >> Hello, Bill. > >> > >> > >>> Has anyone gotten the latest/greatest sources from the LLVM-GCC open > >>> source server lately? > >>> > >> No. It's still at rev 319 (as of 29.04). > >> > >> > > Yeesh...Okay, I'm working with Jeff C. to get a copy of the TOT out to > > people. I'm also pinging the rsync wonks here to see if there's > > something amiss. > > > > -bw > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > > > > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From isanbard at gmail.com Fri May 4 19:01:20 2007 From: isanbard at gmail.com (Bill) Date: Fri, 4 May 2007 17:01:20 -0700 Subject: [LLVMdev] LLVM-GCC Back Message-ID: <16e5fdf90705041701n175fa3e4xadfcbdbbc6111222@mail.gmail.com> The LLVM-GCC anonymous mirror should be updated now. Let me know if this happens again. -bw From jeffc at jolt-lang.org Sat May 5 08:44:17 2007 From: jeffc at jolt-lang.org (Jeff Cohen) Date: Sat, 05 May 2007 06:44:17 -0700 Subject: [LLVMdev] LLVM-GCC Back In-Reply-To: <16e5fdf90705041701n175fa3e4xadfcbdbbc6111222@mail.gmail.com> References: <16e5fdf90705041701n175fa3e4xadfcbdbbc6111222@mail.gmail.com> Message-ID: <463C8A31.7040709@jolt-lang.org> Bill wrote: > The LLVM-GCC anonymous mirror should be updated now. Let me know if > this happens again. > > -bw It's still taking over an hour for rsync to occur. From greened at obbligato.org Sat May 5 14:33:51 2007 From: greened at obbligato.org (David Greene) Date: Sat, 05 May 2007 14:33:51 -0500 Subject: [LLVMdev] 1 Week Before 2.0 Branch Creation In-Reply-To: References: <463B56EA.5060303@obbligato.org> Message-ID: <463CDC1F.2060907@obbligato.org> Tanya M. Lattner wrote: > How large of a change have you made? With 3 days before the branch > creation, I strongly advise people not to be checking in major changes. Depends how you look at it. Structurally, it separates two files into four and moves some functionality from one class to a new class, so in a sense that's a big change. Code-logic-wise, it does nothing at all. I will send the patch to the commits list today. Hopefully someone can look at it and decide whether to apply it. > We may need to change our proceedures for releases in the future. > This is how we have done it in the past with no problem, but LLVM is > growing much more rapidly now. In my experience, a code freeze lasts for a fair amount of time (on the order of months). The way I've seen it done in many projects is that there's a deadline to get all new feature work in (with more than a week's notice!). Then the new branch is created. The next two or three months, only bugfixes are allowed on the release branch. Some projects close the development branch to force bugs to be fixed first, while others run two branches in parallel. I would lean toward the latter and trust people to be responsible enough to fix bugs before release. The release is done when there are no new regressions and all tests created for new features pass. Of course, this means that folks should be creating tests for their features. Do we want some kind of discussion about what this process should be followed by a formal proposal drafted by a few people for comment and possible adoption? -Dave From angray at beeb.net Sat May 5 14:33:42 2007 From: angray at beeb.net (Aaron Gray) Date: Sat, 5 May 2007 20:33:42 +0100 Subject: [LLVMdev] LLVM and LLVM-GCC4 build on GCC 4.2.0 RC3 Message-ID: <00f501c78f4c$4a55c550$0200a8c0@AMD2500> I have successfully built LLVM and LLVM-GCC4 on GCC-4.2.0-20070501 on Linux x86 32bit. GCC 4.2.0 RC3 is availiable from :- ftp://gcc.gnu.org/pub/gcc/prerelease-4.2.0-20070501 Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20070505/5535bb23/attachment.html From sabre at nondot.org Sat May 5 15:47:01 2007 From: sabre at nondot.org (Chris Lattner) Date: Sat, 5 May 2007 13:47:01 -0700 (PDT) Subject: [LLVMdev] LLVM and LLVM-GCC4 build on GCC 4.2.0 RC3 In-Reply-To: <00f501c78f4c$4a55c550$0200a8c0@AMD2500> References: <00f501c78f4c$4a55c550$0200a8c0@AMD2500> Message-ID: On Sat, 5 May 2007, Aaron Gray wrote: > I have successfully built LLVM and LLVM-GCC4 on GCC-4.2.0-20070501 on > Linux x86 32bit. > > GCC 4.2.0 RC3 is availiable from :- > > ftp://gcc.gnu.org/pub/gcc/prerelease-4.2.0-20070501 Great news! -Chris -- http://nondot.org/sabre/ http://llvm.org/ From angray at beeb.net Sat May 5 14:44:24 2007 From: angray at beeb.net (Aaron Gray) Date: Sat, 5 May 2007 20:44:24 +0100 Subject: [LLVMdev] 1 Week Before 2.0 Branch Creation References: <463B56EA.5060303@obbligato.org> <463CDC1F.2060907@obbligato.org> Message-ID: <010201c78f4d$c8f1ebe0$0200a8c0@AMD2500> > Tanya M. Lattner wrote: > >> How large of a change have you made? With 3 days before the branch >> creation, I strongly advise people not to be checking in major changes. > > Depends how you look at it. Structurally, it separates two files into > four and moves some functionality from one class to a new class, so in a > sense that's a big change. Code-logic-wise, it does nothing at all. I > will send the patch to the commits list today. Hopefully someone can > look at it and decide whether to apply it. > > > We may need to change our proceedures for releases in the future. > > This is how we have done it in the past with no problem, but LLVM is > > growing much more rapidly now. > > In my experience, a code freeze lasts for a fair amount of time (on the > order of months). The way I've seen it done in many projects is that > there's a deadline to get all new feature work in (with more than a > week's notice!). Then the new branch is created. The next two or three > months, only bugfixes are allowed on the release branch. Some projects > close the development branch to force bugs to be fixed first, while > others run two branches in parallel. I would lean toward the latter and > trust people to be responsible enough to fix bugs before release. > > The release is done when there are no new regressions and all tests > created for new features pass. Of course, this means that folks > should be creating tests for their features. > > Do we want some kind of discussion about what this process should be > followed by a formal proposal drafted by a few people for comment and > possible adoption? It would be good to have a mailing list for test results where 'make check' results could be posted so that there is some reference and people could avoid repeating builds. Aaron From sabre at nondot.org Sat May 5 15:59:10 2007 From: sabre at nondot.org (Chris Lattner) Date: Sat, 5 May 2007 13:59:10 -0700 (PDT) Subject: [LLVMdev] 1 Week Before 2.0 Branch Creation In-Reply-To: <010201c78f4d$c8f1ebe0$0200a8c0@AMD2500> References: <463B56EA.5060303@obbligato.org> <463CDC1F.2060907@obbligato.org> <010201c78f4d$c8f1ebe0$0200a8c0@AMD2500> Message-ID: On Sat, 5 May 2007, Aaron Gray wrote: > It would be good to have a mailing list for test results where 'make check' > results could be posted so that there is some reference and people could > avoid repeating builds. llvm-testresults :) -Chris -- http://nondot.org/sabre/ http://llvm.org/ From angray at beeb.net Sat May 5 14:59:14 2007 From: angray at beeb.net (Aaron Gray) Date: Sat, 5 May 2007 20:59:14 +0100 Subject: [LLVMdev] LLVM and LLVM-GCC4 build on GCC 4.2.0 RC3 References: <00f501c78f4c$4a55c550$0200a8c0@AMD2500> Message-ID: <012701c78f4f$db5ad560$0200a8c0@AMD2500> > On Sat, 5 May 2007, Aaron Gray wrote: >> I have successfully built LLVM and LLVM-GCC4 on GCC-4.2.0-20070501 on >> Linux x86 32bit. >> >> GCC 4.2.0 RC3 is availiable from :- >> >> ftp://gcc.gnu.org/pub/gcc/prerelease-4.2.0-20070501 > > Great news! I will try building GCC 4.2.0 RC3 on Cygwin. GCC-4.3-20070427 builds on Cygwin but does not build LLVM. Aaron From angray at beeb.net Sat May 5 14:59:24 2007 From: angray at beeb.net (Aaron Gray) Date: Sat, 5 May 2007 20:59:24 +0100 Subject: [LLVMdev] 1 Week Before 2.0 Branch Creation References: <463B56EA.5060303@obbligato.org><463CDC1F.2060907@obbligato.org><010201c78f4d$c8f1ebe0$0200a8c0@AMD2500> Message-ID: <012801c78f4f$e180c710$0200a8c0@AMD2500> > On Sat, 5 May 2007, Aaron Gray wrote: >> It would be good to have a mailing list for test results where 'make >> check' >> results could be posted so that there is some reference and people could >> avoid repeating builds. > > llvm-testresults :) Great, feeling silly, I'll signon to that then :) Aaron From greened at obbligato.org Sat May 5 15:09:08 2007 From: greened at obbligato.org (David Greene) Date: Sat, 05 May 2007 15:09:08 -0500 Subject: [LLVMdev] 1 Week Before 2.0 Branch Creation In-Reply-To: <010201c78f4d$c8f1ebe0$0200a8c0@AMD2500> References: <463B56EA.5060303@obbligato.org> <463CDC1F.2060907@obbligato.org> <010201c78f4d$c8f1ebe0$0200a8c0@AMD2500> Message-ID: <463CE464.9000400@obbligato.org> Aaron Gray wrote: > It would be good to have a mailing list for test results where 'make check' > results could be posted so that there is some reference and people could > avoid repeating builds. There's the llvm-testresults list, but I find it less than fully useful because it's not immediately obvious from scanning message subjects if there's been a test failure. It's a lot of messages to wade through and read to get this information. What about a Tinderbox-like setup where we could consult a web page to see the current status of the repository? Boost has a nice setup: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/developer/index_release.html It's probably more complex than what we need. Maybe we just need a page grouping each test under it's suite and marking the result on each architecture. Something like this: --------------------------------------------------------------------------- | LLVM | Arch | i686-pc-linux-gnu | darwin- | osx.. --------------------------------------------------------------------------- | Suite | Test | Witty note to brighten developer day --------------------------------------------------------------------------- | CFrontend | 2002-05-24-Alloca.c | PASS | FAIL | XFAIL | | ... | | | --------------------------------------------------------------------------- | CBackend | ... | | | | ... | | | | FAILs would of course be marked in something pleasant like flourescent bright-magenta. Just an idea. Wow, I already wasted more of a Saturday on that than I should have. :-/ -Dave From angray at beeb.net Sat May 5 15:21:44 2007 From: angray at beeb.net (Aaron Gray) Date: Sat, 5 May 2007 21:21:44 +0100 Subject: [LLVMdev] 1 Week Before 2.0 Branch Creation References: <463B56EA.5060303@obbligato.org><463CDC1F.2060907@obbligato.org><010201c78f4d$c8f1ebe0$0200a8c0@AMD2500> <012801c78f4f$e180c710$0200a8c0@AMD2500> Message-ID: <014a01c78f53$0021a150$0200a8c0@AMD2500> >> On Sat, 5 May 2007, Aaron Gray wrote: >>> It would be good to have a mailing list for test results where 'make >>> check' >>> results could be posted so that there is some reference and people could >>> avoid repeating builds. >> >> llvm-testresults :) > > Great, feeling silly, I'll signon to that then :) Shall attach results or put them inline ? Aaron From sabre at nondot.org Sat May 5 16:34:32 2007 From: sabre at nondot.org (Chris Lattner) Date: Sat, 5 May 2007 14:34:32 -0700 (PDT) Subject: [LLVMdev] 1 Week Before 2.0 Branch Creation In-Reply-To: <463CDC1F.2060907@obbligato.org> References: <463B56EA.5060303@obbligato.org> <463CDC1F.2060907@obbligato.org> Message-ID: On Sat, 5 May 2007, David Greene wrote: > Tanya M. Lattner wrote: >> How large of a change have you made? With 3 days before the branch >> creation, I strongly advise people not to be checking in major changes. > Depends how you look at it. Structurally, it separates two files into > four and moves some functionality from one class to a new class, so in a > sense that's a big change. Code-logic-wise, it does nothing at all. I > will send the patch to the commits list today. Hopefully someone can > look at it and decide whether to apply it. This sounds like great stuff, and is definitely progress towards a better RA. However, it doesn't provide any user-visible feature, so I think it makes sense to apply this immediately after 2.0 branches, just to reduce risk. > > We may need to change our proceedures for releases in the future. > > This is how we have done it in the past with no problem, but LLVM is > > growing much more rapidly now. > The way I've seen it done in many projects is that > there's a deadline to get all new feature work in (with more than a > week's notice!). Then the new branch is created. To be fair, this has been the plan for quite some time: http://lists.cs.uiuc.edu/pipermail/llvmdev/2007-March/008322.html We should probably find a way to publicize this better on the web page. As an aside, the web page definitely needs a major overhaul :) > In my experience, a code freeze lasts for a fair amount of time (on the > order of months). The next two or three months, only bugfixes are > allowed on the release branch. Some projects close the development > branch to force bugs to be fixed first, while others run two branches in > parallel. I would lean toward the latter and trust people to be > responsible enough to fix bugs before release. Right, this is a very common approach, used by many projects. For LLVM, we have traditionally taken a different approach: keep mainline as stable as possible at all times, then make the release branch a short cycle that only accepts *critical* bug fixes (even things like miscompilations or compile crashes aren't taken if they are at all risky). The idea is that we always keep mainline CVS close to release quality. This is good for everyone doing daily development of course. In practice, minor regressions occasionally slip in during the development cycle, so the tree isn't *always* happy. However, these problems are usually "shallow" problems that are easily fixed, they don't require major new rearchitecture, etc. One major difference between LLVM and some other projects is that we usually promptly fix incoming bug reports (particularly regressions) as they happen, on mainline. There is no need to wait for a release branch for this. In general, branches are an extremely expensive way to spend human time. I prefer to keep branches (release and otherwise) as minimal and short-lived as possible. This is one reason that we almost never use branches for mainline development, even for large projects: we find a way to break the project down into incremental pieces, which are independently easy to test and are less scary than the big rewrite :) > The release is done when there are no new regressions and all tests > created for new features pass. Of course, this means that folks > should be creating tests for their features. Absolutely. We definitely do this today. In general, I think that the LLVM project has done an excellent job of making each release monotonically better than the previous one. LLVM 2.0 has been used to compile *large* quanitites of source code. While it contains a large number of new features, I am quite confident it will be our best release yet. > Do we want some kind of discussion about what this process should be > followed by a formal proposal drafted by a few people for comment and > possible adoption? Sure, I think that makes sense. -Chris -- http://nondot.org/sabre/ http://llvm.org/ From sabre at nondot.org Sat May 5 16:35:50 2007 From: sabre at nondot.org (Chris Lattner) Date: Sat, 5 May 2007 14:35:50 -0700 (PDT) Subject: [LLVMdev] 1 Week Before 2.0 Branch Creation In-Reply-To: <014a01c78f53$0021a150$0200a8c0@AMD2500> References: <463B56EA.5060303@obbligato.org><463CDC1F.2060907@obbligato.org><010201c78f4d$c8f1ebe0$0200a8c0@AMD2500> <012801c78f4f$e180c710$0200a8c0@AMD2500> <014a01c78f53$0021a150$0200a8c0@AMD2500> Message-ID: On Sat, 5 May 2007, Aaron Gray wrote: >>> On Sat, 5 May 2007, Aaron Gray wrote: >>>> It would be good to have a mailing list for test results where 'make >>>> check' >>>> results could be posted so that there is some reference and people could >>>> avoid repeating builds. >>> >>> llvm-testresults :) >> >> Great, feeling silly, I'll signon to that then :) > > Shall attach results or put them inline ? Either way, just don't rot13 them or something :) -Chris -- http://nondot.org/sabre/ http://llvm.org/ From isanbard at gmail.com Sat May 5 15:36:44 2007 From: isanbard at gmail.com (Bill Wendling) Date: Sat, 5 May 2007 13:36:44 -0700 Subject: [LLVMdev] LLVM-GCC Back In-Reply-To: <463C8A31.7040709@jolt-lang.org> References: <16e5fdf90705041701n175fa3e4xadfcbdbbc6111222@mail.gmail.com> <463C8A31.7040709@jolt-lang.org> Message-ID: <7D410BA6-1EE0-40F9-B59F-DCC931BB3F8E@gmail.com> On May 5, 2007, at 6:44 AM, Jeff Cohen wrote: > Bill wrote: >> The LLVM-GCC anonymous mirror should be updated now. Let me know if >> this happens again. >> >> -bw > > It's still taking over an hour for rsync to occur. > I can try to see if they will move the rsync to a better time. Unfortunately, I don't have much control over that end of it. Would it be possible to run your nightly script later? :-) -bw From sabre at nondot.org Sat May 5 16:42:06 2007 From: sabre at nondot.org (Chris Lattner) Date: Sat, 5 May 2007 14:42:06 -0700 (PDT) Subject: [LLVMdev] 1 Week Before 2.0 Branch Creation In-Reply-To: <463CE464.9000400@obbligato.org> References: <463B56EA.5060303@obbligato.org> <463CDC1F.2060907@obbligato.org> <010201c78f4d$c8f1ebe0$0200a8c0@AMD2500> <463CE464.9000400@obbligato.org> Message-ID: On Sat, 5 May 2007, David Greene wrote: > There's the llvm-testresults list, but I find it less than fully useful > because it's not immediately obvious from scanning message subjects if > there's been a test failure. It's a lot of messages to wade through and > read to get this information. Right. > What about a Tinderbox-like setup where we could consult a web page to > see the current status of the repository? Boost has a nice setup: > > http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/developer/index_release.html > > It's probably more complex than what we need. Maybe we just need a > page grouping each test under it's suite and marking the result on > each architecture. Something like this: I think that this is a great idea. However, instead of picking up yet another setting of testing infrastructure, I think we should make what we have already (the nightly testers) better. In particular, the main page of the tester: http://llvm.org/nightlytest/ Already captures a lot of this: it tells you the number of unexpected failures, whether or not the build succeeded etc. You can even drill down to a specific machine, e.g.: http://llvm.org/nightlytest/machine.php?machine=120 I see several problems with this, all of which are solvable: 1. The tester script doesn't update and rebuild the CFE, so often you get failures due to an out-of-date CFE. 2. There is no way to group by architecture, target-triple, etc. 3. Minor stupid stuff: on the per-machine page, you can click on the test failures number and go to the list of unexpected failures, but you can't do that on the main page. -Chris -- http://nondot.org/sabre/ http://llvm.org/ From jeffc at jolt-lang.org Sat May 5 15:39:08 2007 From: jeffc at jolt-lang.org (Jeff Cohen) Date: Sat, 05 May 2007 13:39:08 -0700 Subject: [LLVMdev] 1 Week Before 2.0 Branch Creation In-Reply-To: <014a01c78f53$0021a150$0200a8c0@AMD2500> References: <463B56EA.5060303@obbligato.org><463CDC1F.2060907@obbligato.org><010201c78f4d$c8f1ebe0$0200a8c0@AMD2500> <012801c78f4f$e180c710$0200a8c0@AMD2500> <014a01c78f53$0021a150$0200a8c0@AMD2500> Message-ID: <463CEB6C.5020304@jolt-lang.org> Aaron Gray wrote: >>> On Sat, 5 May 2007, Aaron Gray wrote: >>> >>>> It would be good to have a mailing list for test results where 'make >>>> check' >>>> results could be posted so that there is some reference and people could >>>> avoid repeating builds. >>>> >>> llvm-testresults :) >>> >> Great, feeling silly, I'll signon to that then :) >> > > Shall attach results or put them inline ? > > Aaron What you see on llvm-testresults are posted automatically by running the nightly tester. From jeffc at jolt-lang.org Sat May 5 15:40:50 2007 From: jeffc at jolt-lang.org (Jeff Cohen) Date: Sat, 05 May 2007 13:40:50 -0700 Subject: [LLVMdev] LLVM-GCC Back In-Reply-To: <7D410BA6-1EE0-40F9-B59F-DCC931BB3F8E@gmail.com> References: <16e5fdf90705041701n175fa3e4xadfcbdbbc6111222@mail.gmail.com> <463C8A31.7040709@jolt-lang.org> <7D410BA6-1EE0-40F9-B59F-DCC931BB3F8E@gmail.com> Message-ID: <463CEBD2.5040604@jolt-lang.org> Bill Wendling wrote: > On May 5, 2007, at 6:44 AM, Jeff Cohen wrote: > >> Bill wrote: >>> The LLVM-GCC anonymous mirror should be updated now. Let me know if >>> this happens again. >>> >>> -bw >> >> It's still taking over an hour for rsync to occur. >> > I can try to see if they will move the rsync to a better time. > Unfortunately, I don't have much control over that end of it. Would it > be possible to run your nightly script later? :-) > > -bw How much later? When does it occur? I don't want to run it too much later, because it won't be finished when I'm trying to use it in the morning (and the most memory-intensive part runs last). From isanbard at gmail.com Sat May 5 15:48:42 2007 From: isanbard at gmail.com (Bill Wendling) Date: Sat, 5 May 2007 13:48:42 -0700 Subject: [LLVMdev] LLVM-GCC Back In-Reply-To: <463CEBD2.5040604@jolt-lang.org> References: <16e5fdf90705041701n175fa3e4xadfcbdbbc6111222@mail.gmail.com> <463C8A31.7040709@jolt-lang.org> <7D410BA6-1EE0-40F9-B59F-DCC931BB3F8E@gmail.com> <463CEBD2.5040604@jolt-lang.org> Message-ID: On May 5, 2007, at 1:40 PM, Jeff Cohen wrote: > Bill Wendling wrote: >> On May 5, 2007, at 6:44 AM, Jeff Cohen wrote: >> >>> Bill wrote: >>>> The LLVM-GCC anonymous mirror should be updated now. Let me know if >>>> this happens again. >>>> >>>> -bw >>> >>> It's still taking over an hour for rsync to occur. >>> >> I can try to see if they will move the rsync to a better time. >> Unfortunately, I don't have much control over that end of it. >> Would it be possible to run your nightly script later? :-) >> >> -bw > > How much later? When does it occur? > > I don't want to run it too much later, because it won't be finished > when I'm trying to use it in the morning (and the most memory- > intensive part runs last). > I'll ping the guy who's in charge of the sync and ask him when it's done. Right now, the copy to the Apple internal mirror is done at 2AM PDT. From your email, I suspect that the sync is done around 3ish. Though maybe it's somehow dependent upon when I update the mirror?? Unfortunately, because we now have people working on LLVM around the clock (hi Anton! :-) ), pretty much anytime for the sync is going to be a problem for someone. The good news is that this problem will be obviated in about a month! :-) -bw From jeffc at jolt-lang.org Sat May 5 15:57:31 2007 From: jeffc at jolt-lang.org (Jeff Cohen) Date: Sat, 05 May 2007 13:57:31 -0700 Subject: [LLVMdev] LLVM-GCC Back In-Reply-To: References: <16e5fdf90705041701n175fa3e4xadfcbdbbc6111222@mail.gmail.com> <463C8A31.7040709@jolt-lang.org> <7D410BA6-1EE0-40F9-B59F-DCC931BB3F8E@gmail.com> <463CEBD2.5040604@jolt-lang.org> Message-ID: <463CEFBB.1080003@jolt-lang.org> Bill Wendling wrote: > On May 5, 2007, at 1:40 PM, Jeff Cohen wrote: > >> Bill Wendling wrote: >>> On May 5, 2007, at 6:44 AM, Jeff Cohen wrote: >>> >>>> Bill wrote: >>>>> The LLVM-GCC anonymous mirror should be updated now. Let me know if >>>>> this happens again. >>>>> >>>>> -bw >>>> >>>> It's still taking over an hour for rsync to occur. >>>> >>> I can try to see if they will move the rsync to a better time. >>> Unfortunately, I don't have much control over that end of it. Would >>> it be possible to run your nightly script later? :-) >>> >>> -bw >> >> How much later? When does it occur? >> >> I don't want to run it too much later, because it won't be finished >> when I'm trying to use it in the morning (and the most >> memory-intensive part runs last). >> > I'll ping the guy who's in charge of the sync and ask him when it's > done. Right now, the copy to the Apple internal mirror is done at 2AM > PDT. From your email, I suspect that the sync is done around 3ish. > Though maybe it's somehow dependent upon when I update the mirror?? > > Unfortunately, because we now have people working on LLVM around the > clock (hi Anton! :-) ), pretty much anytime for the sync is going to > be a problem for someone. The good news is that this problem will be > obviated in about a month! :-) > > -bw I delayed it to 3:40am. We'll see if that's late enough. From angray at beeb.net Sat May 5 15:57:17 2007 From: angray at beeb.net (Aaron Gray) Date: Sat, 5 May 2007 21:57:17 +0100 Subject: [LLVMdev] 1 Week Before 2.0 Branch Creation References: <463B56EA.5060303@obbligato.org><463CDC1F.2060907@obbligato.org><010201c78f4d$c8f1ebe0$0200a8c0@AMD2500> <012801c78f4f$e180c710$0200a8c0@AMD2500><014a01c78f53$0021a150$0200a8c0@AMD2500> <463CEB6C.5020304@jolt-lang.org> Message-ID: <019201c78f57$f7dad930$0200a8c0@AMD2500> > Aaron Gray wrote: >>>> On Sat, 5 May 2007, Aaron Gray wrote: >>>> >>>>> It would be good to have a mailing list for test results where 'make >>>>> check' >>>>> results could be posted so that there is some reference and people >>>>> could >>>>> avoid repeating builds. >>>>> >>>> llvm-testresults :) >>>> >>> Great, feeling silly, I'll signon to that then :) >>> >> >> Shall attach results or put them inline ? >> >> Aaron > > What you see on llvm-testresults are posted automatically by running the > nightly tester. Thanks, yes I gathered that, just signed on to the list so its newish territory. Aaron From tonic at nondot.org Sat May 5 17:48:14 2007 From: tonic at nondot.org (Tanya M. Lattner) Date: Sat, 5 May 2007 15:48:14 -0700 (PDT) Subject: [LLVMdev] 1 Week Before 2.0 Branch Creation In-Reply-To: <463CDC1F.2060907@obbligato.org> References: <463B56EA.5060303@obbligato.org> <463CDC1F.2060907@obbligato.org> Message-ID: >> How large of a change have you made? With 3 days before the branch >> creation, I strongly advise people not to be checking in major changes. > > Depends how you look at it. Structurally, it separates two files into > four and moves some functionality from one class to a new class, so in a > sense that's a big change. Code-logic-wise, it does nothing at all. I > will send the patch to the commits list today. Hopefully someone can > look at it and decide whether to apply it. While its not necessarily a large functionality change, its probably too much to review with this notice. Chris would have final say on this, but in general its bit close to the deadline. > > We may need to change our proceedures for releases in the future. > > This is how we have done it in the past with no problem, but LLVM is > > growing much more rapidly now. > > In my experience, a code freeze lasts for a fair amount of time (on the > order of months). The way I've seen it done in many projects is that > there's a deadline to get all new feature work in (with more than a > week's notice!). Then the new branch is created. The next two or three > months, only bugfixes are allowed on the release branch. Some projects > close the development branch to force bugs to be fixed first, while > others run two branches in parallel. I would lean toward the latter and > trust people to be responsible enough to fix bugs before release. In my defense, there has been more than one email about the release schedule. In the future, I will send them out more often and also find a good place to put this on our webpage (I've been meaning to overhaul it, but havent had time). > The release is done when there are no new regressions and all tests > created for new features pass. Of course, this means that folks > should be creating tests for their features. This is the case today. I verify on our major platforms that there are no regressions from the previous release. Older releases may not have been as strict with this requirement (pre 1.7 I was not the release manager). Regressions should be fixed and we do delay the release if necessary. > Do we want some kind of discussion about what this process should be > followed by a formal proposal drafted by a few people for comment and > possible adoption? You should be aware of this: http://llvm.org/docs/HowToReleaseLLVM.html Some of the process is not documented, but I always send emails about the next steps. You can look back in the mailing archives to see how we have done this is in the past. Since this is my domain, I will draft something up. However, nothing will change for this release. -Tanya From tonic at nondot.org Sat May 5 17:50:48 2007 From: tonic at nondot.org (Tanya M. Lattner) Date: Sat, 5 May 2007 15:50:48 -0700 (PDT) Subject: [LLVMdev] 1 Week Before 2.0 Branch Creation In-Reply-To: <463CE464.9000400@obbligato.org> References: <463B56EA.5060303@obbligato.org> <463CDC1F.2060907@obbligato.org> <010201c78f4d$c8f1ebe0$0200a8c0@AMD2500> <463CE464.9000400@obbligato.org> Message-ID: >> It would be good to have a mailing list for test results where 'make check' >> results could be posted so that there is some reference and people could >> avoid repeating builds. > > There's the llvm-testresults list, but I find it less than fully useful > because it's not immediately obvious from scanning message subjects if > there's been a test failure. It's a lot of messages to wade through and > read to get this information. > > What about a Tinderbox-like setup where we could consult a web page to > see the current status of the repository? Boost has a nice setup: > > http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/developer/index_release.html > > It's probably more complex than what we need. Maybe we just need a > page grouping each test under it's suite and marking the result on > each architecture. Something like this: I agree the test results are not displayed well. Its not well known, but I have been redesigning our databases and scripts to enable better display of the data. Right now its not very easy to do what you describe. -Tanya From gabor at mac.com Sat May 5 17:53:49 2007 From: gabor at mac.com (Gabor Greif) Date: Sun, 6 May 2007 00:53:49 +0200 Subject: [LLVMdev] 1 Week Before 2.0 Branch Creation Message-ID: Chris wrote: > I see several problems with this, all of which are solvable: > ... [items snipped] 4. The page does not show the server's current time, so the times of the test machines cannot be related to "now". > -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20070506/a2f72a67/attachment.html From lefever at crhc.uiuc.edu Sat May 5 19:32:08 2007 From: lefever at crhc.uiuc.edu (Ryan M. Lefever) Date: Sat, 05 May 2007 19:32:08 -0500 Subject: [LLVMdev] understanding llvm-test Message-ID: <463D2208.5080807@crhc.uiuc.edu> I need some benchmarks to test some compiler passes on which I've been working. So, I've been looking through llvm-test. I read through the "LLVM Test Suite Guide" at http://llvm.org/docs/TestingGuide.html, and I have a few questions. In particular, in the "Running the LLVM Tests" section, it says that some tests are known to fail. Indeed when I've done a make inside llvm-test, I get notices like: ******************** TEST (llc) 'simple' FAILED! ******************** or ******************** TEST (cbe) 'simple' FAILED! ******************** - How do I know which tests are supposed to fail and which ones failed but should not have failed? - It appears that once a piece of code is run through a backend, the result is executed and compared to the execution of the code after being run through the native backend. So, is there anyway to know if what the native backend produced is correct? Or, do I just assume that if the native backend compiles a piece of code, then it is correct? Regards, Ryan -- Ryan M. Lefever [http://www.ews.uiuc.edu/~lefever] From sabre at nondot.org Sat May 5 20:49:55 2007 From: sabre at nondot.org (Chris Lattner) Date: Sat, 5 May 2007 18:49:55 -0700 (PDT) Subject: [LLVMdev] CREDITS.TXT Message-ID: Reminder: please update your credits.txt entry for the 2.0 release. Also, if you have contributed a patch to LLVM, and are not listed here: http://llvm.org/developers.cgi Please get yourself added! :) -Chris -- http://nondot.org/sabre/ http://llvm.org/ From isanbard at gmail.com Sat May 5 16:11:05 2007 From: isanbard at gmail.com (Bill Wendling) Date: Sat, 5 May 2007 14:11:05 -0700 Subject: [LLVMdev] GMP Message-ID: <1F482F79-B8E3-4026-BBF5-E7D0FA8765CF@gmail.com> With Chris' latest fix, GMP now builds and passes all of its tests! Yay!! -bw From sabre at nondot.org Sun May 6 06:07:49 2007 From: sabre at nondot.org (Chris Lattner) Date: Sun, 6 May 2007 04:07:49 -0700 (PDT) Subject: [LLVMdev] goodbye bytecode, hello bitcode Message-ID: I just checked in the final bits to switch us over from bytecode to bitcode. Old bytecode files will not work, but I expect this format to be stable going forward with the 2.x series of releases. This new format has a number of advantages. In particular: 1. The files are smaller. 2. The reader takes about 2/3 the memory it did before. 3. The reader is about 1/2 the code size of the old reader. 4. We don't need to carry around bzip2 etc 5. The new format is *much* easier to keep stable going forward. Please let me know if you run into any problems. Documentation of the file format is in the works. The bytecode support code is still in the tree, but isn't being built. Assuming no major problems, I will remove the old code tomorrow. -Chris -- http://nondot.org/sabre/ http://llvm.org/ From ralph at inputplus.co.uk Sun May 6 05:55:30 2007 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Sun, 06 May 2007 11:55:30 +0100 Subject: [LLVMdev] 1 Week Before 2.0 Branch Creation In-Reply-To: References: <463B56EA.5060303@obbligato.org> <463CDC1F.2060907@obbligato.org> <010201c78f4d$c8f1ebe0$0200a8c0@AMD2500> <463CE464.9000400@obbligato.org> Message-ID: <20070506105530.7820C149125@blake.inputplus.co.uk> Hi Chris, > I think that this is a great idea. However, instead of picking up yet > another setting of testing infrastructure, I think we should make what > we have already (the nightly testers) better. In particular, the main > page of the tester: > http://llvm.org/nightlytest/ > > Already captures a lot of this: it tells you the number of unexpected > failures, whether or not the build succeeded etc. You can even drill > down to a specific machine, e.g.: > http://llvm.org/nightlytest/machine.php?machine=120 > > I see several problems with this, all of which are solvable: > > 1. The tester script doesn't update and rebuild the CFE, so often you > get failures due to an out-of-date CFE. > 2. There is no way to group by architecture, target-triple, etc. > 3. Minor stupid stuff: on the per-machine page, you can click on the > test failures number and go to the list of unexpected failures, but > you can't do that on the main page. Are you aware of buildbot? It's quite widely used and flexible. http://buildbot.sourceforge.net/ "By automatically rebuilding and testing the tree each time something has changed, build problems are pinpointed quickly, before other developers are inconvenienced by the failure. The guilty developer can be **identified and harassed without human intervention**. By running the builds on a variety of platforms, developers who do not have the facilities to test their changes everywhere before checkin will at least know shortly afterwards whether they have broken the build or not. Warning counts, lint checks, image size, compile time, and other build parameters can be tracked over time, are more visible, and are therefore easier to improve." ** -- my emphasis. I'd suggest at least one machine given over to always building whenever anything changes, and have the other nightly volunteers as now. Using just nightly volunteers isn't great because breakage is noticed too late and can affect too many people by then. An example of the output is http://www.python.org/dev/buildbot/trunk/ Cheers, Ralph. From jeffc at jolt-lang.org Sun May 6 08:45:36 2007 From: jeffc at jolt-lang.org (Jeff Cohen) Date: Sun, 06 May 2007 06:45:36 -0700 Subject: [LLVMdev] LLVM-GCC Back In-Reply-To: <463CEFBB.1080003@jolt-lang.org> References: <16e5fdf90705041701n175fa3e4xadfcbdbbc6111222@mail.gmail.com> <463C8A31.7040709@jolt-lang.org> <7D410BA6-1EE0-40F9-B59F-DCC931BB3F8E@gmail.com> <463CEBD2.5040604@jolt-lang.org> <463CEFBB.1080003@jolt-lang.org> Message-ID: <463DDC00.90202@jolt-lang.org> Jeff Cohen wrote: > Bill Wendling wrote: > >>> I'll ping the guy who's in charge of the sync and ask him when it's >>> done. Right now, the copy to the Apple internal mirror is done at 2AM >>> PDT. From your email, I suspect that the sync is done around 3ish. >>> Though maybe it's somehow dependent upon when I update the mirror?? >>> >>> Unfortunately, because we now have people working on LLVM around the >>> clock (hi Anton! :-) ), pretty much anytime for the sync is going to >>> be a problem for someone. The good news is that this problem will be >>> obviated in about a month! :-) >>> >>> -bw >>> > > I delayed it to 3:40am. We'll see if that's late enough. The answer is no. It is not late enough. llvm-gcc failed to build as a result (yet again) and the nightly tester did not run. From jeffc at jolt-lang.org Sun May 6 09:07:38 2007 From: jeffc at jolt-lang.org (Jeff Cohen) Date: Sun, 06 May 2007 07:07:38 -0700 Subject: [LLVMdev] LLVM-GCC Back In-Reply-To: <463DDC00.90202@jolt-lang.org> References: <16e5fdf90705041701n175fa3e4xadfcbdbbc6111222@mail.gmail.com> <463C8A31.7040709@jolt-lang.org> <7D410BA6-1EE0-40F9-B59F-DCC931BB3F8E@gmail.com> <463CEBD2.5040604@jolt-lang.org> <463CEFBB.1080003@jolt-lang.org> <463DDC00.90202@jolt-lang.org> Message-ID: <463DE12A.3010605@jolt-lang.org> Jeff Cohen wrote: > Jeff Cohen wrote: > >> Bill Wendling wrote: >> >> >>>> I'll ping the guy who's in charge of the sync and ask him when it's >>>> done. Right now, the copy to the Apple internal mirror is done at 2AM >>>> PDT. From your email, I suspect that the sync is done around 3ish. >>>> Though maybe it's somehow dependent upon when I update the mirror?? >>>> >>>> Unfortunately, because we now have people working on LLVM around the >>>> clock (hi Anton! :-) ), pretty much anytime for the sync is going to >>>> be a problem for someone. The good news is that this problem will be >>>> obviated in about a month! :-) >>>> >>>> -bw >>>> >>>> >> I delayed it to 3:40am. We'll see if that's late enough. >> > > The answer is no. It is not late enough. llvm-gcc failed to build as a > result (yet again) and the nightly tester did not run. And even if the mirror was promptly updated at 2am, it wouldn't have mattered. The mirror got fatally out of sync with llvm less than an hour later. There are still massive errors building llvm-gcc. And the Visual Studio build is massively broken too. I don't have time to fix it today. From rspencer at reidspencer.com Sun May 6 11:06:15 2007 From: rspencer at reidspencer.com (Reid Spencer) Date: Sun, 06 May 2007 09:06:15 -0700 Subject: [LLVMdev] LLVM-GCC Back In-Reply-To: <463DE12A.3010605@jolt-lang.org> References: <16e5fdf90705041701n175fa3e4xadfcbdbbc6111222@mail.gmail.com> <463C8A31.7040709@jolt-lang.org> <7D410BA6-1EE0-40F9-B59F-DCC931BB3F8E@gmail.com> <463CEBD2.5040604@jolt-lang.org> <463CEFBB.1080003@jolt-lang.org> <463DDC00.90202@jolt-lang.org> <463DE12A.3010605@jolt-lang.org> Message-ID: <1178467575.18852.40.camel@bashful.x10sys.com> I think Chris (and I) sent patches to be applied after update. At least, it worked for me just fine at 4:25am Reid. On Sun, 2007-05-06 at 07:07 -0700, Jeff Cohen wrote: > Jeff Cohen wrote: > > Jeff Cohen wrote: > > > >> Bill Wendling wrote: > >> > >> > >>>> I'll ping the guy who's in charge of the sync and ask him when it's > >>>> done. Right now, the copy to the Apple internal mirror is done at 2AM > >>>> PDT. From your email, I suspect that the sync is done around 3ish. > >>>> Though maybe it's somehow dependent upon when I update the mirror?? > >>>> > >>>> Unfortunately, because we now have people working on LLVM around the > >>>> clock (hi Anton! :-) ), pretty much anytime for the sync is going to > >>>> be a problem for someone. The good news is that this problem will be > >>>> obviated in about a month! :-) > >>>> > >>>> -bw > >>>> > >>>> > >> I delayed it to 3:40am. We'll see if that's late enough. > >> > > > > The answer is no. It is not late enough. llvm-gcc failed to build as a > > result (yet again) and the nightly tester did not run. > > And even if the mirror was promptly updated at 2am, it wouldn't have > mattered. The mirror got fatally out of sync with llvm less than an > hour later. There are still massive errors building llvm-gcc. > > And the Visual Studio build is massively broken too. I don't have time > to fix it today. > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From sabre at nondot.org Sun May 6 14:41:40 2007 From: sabre at nondot.org (Chris Lattner) Date: Sun, 6 May 2007 12:41:40 -0700 (PDT) Subject: [LLVMdev] LLVM-GCC Back In-Reply-To: <463DE12A.3010605@jolt-lang.org> References: <16e5fdf90705041701n175fa3e4xadfcbdbbc6111222@mail.gmail.com> <463C8A31.7040709@jolt-lang.org> <7D410BA6-1EE0-40F9-B59F-DCC931BB3F8E@gmail.com> <463CEBD2.5040604@jolt-lang.org> <463CEFBB.1080003@jolt-lang.org> <463DDC00.90202@jolt-lang.org> <463DE12A.3010605@jolt-lang.org> Message-ID: On Sun, 6 May 2007, Jeff Cohen wrote: >>> I delayed it to 3:40am. We'll see if that's late enough. >> >> The answer is no. It is not late enough. llvm-gcc failed to build as a >> result (yet again) and the nightly tester did not run. > > And even if the mirror was promptly updated at 2am, it wouldn't have > mattered. The mirror got fatally out of sync with llvm less than an > hour later. There are still massive errors building llvm-gcc. Yes, as you are finding out, there is no solution other than to drop the whole "mirror" approach entirely. Luckily, we are planning to do just that! I'm sorry that this is such a pain, but it should be over soon. > And the Visual Studio build is massively broken too. I don't have time > to fix it today. I'm sorry for that. I will be checking in changes today to remove the bcreader/writer directories, so please wait until that is done to rebuild the project files. Thanks for the patience Jeff, LLVM 2.0 is almost here - our development process will get better when it does :) -Chris -- http://nondot.org/sabre/ http://llvm.org/ From sabre at nondot.org Sun May 6 19:28:29 2007 From: sabre at nondot.org (Chris Lattner) Date: Sun, 6 May 2007 17:28:29 -0700 (PDT) Subject: [LLVMdev] 1 Week Before 2.0 Branch Creation In-Reply-To: <20070506105530.7820C149125@blake.inputplus.co.uk> References: <463B56EA.5060303@obbligato.org> <463CDC1F.2060907@obbligato.org> <010201c78f4d$c8f1ebe0$0200a8c0@AMD2500> <463CE464.9000400@obbligato.org> <20070506105530.7820C149125@blake.inputplus.co.uk> Message-ID: On Sun, 6 May 2007, Ralph Corderoy wrote: > Are you aware of buildbot? It's quite widely used and flexible. > http://buildbot.sourceforge.net/ > I'd suggest at least one machine given over to always building whenever > anything changes, and have the other nightly volunteers as now. Using > just nightly volunteers isn't great because breakage is noticed too late > and can affect too many people by then. That looks nifty. If someone wanted to set it up on their machine, we could give it a try and see how it works. -Chris -- http://nondot.org/sabre/ http://llvm.org/ From chandlerc at gmail.com Sun May 6 22:35:37 2007 From: chandlerc at gmail.com (Chandler Carruth) Date: Sun, 6 May 2007 23:35:37 -0400 Subject: [LLVMdev] 1 Week Before 2.0 Branch Creation In-Reply-To: References: <463B56EA.5060303@obbligato.org> <463CDC1F.2060907@obbligato.org> <010201c78f4d$c8f1ebe0$0200a8c0@AMD2500> <463CE464.9000400@obbligato.org> <20070506105530.7820C149125@blake.inputplus.co.uk> Message-ID: <18edb2ad0705062035q79f56e4fw82f0f2b6714aa9fe@mail.gmail.com> I don't know if others would be interested as well, but I should be able to set it up at least on one of my machines over the summer, and on a continuing basis if its found useful. Should be at least useful to me with the work I'll be doing on LLVM over the summer. (NB: a speedy x86-64 linux box currently) -Chandler On 5/6/07, Chris Lattner wrote: > > On Sun, 6 May 2007, Ralph Corderoy wrote: > > Are you aware of buildbot? It's quite widely used and flexible. > > http://buildbot.sourceforge.net/ > > I'd suggest at least one machine given over to always building whenever > > anything changes, and have the other nightly volunteers as now. Using > > just nightly volunteers isn't great because breakage is noticed too late > > and can affect too many people by then. > > That looks nifty. If someone wanted to set it up on their machine, we > could give it a try and see how it works. > > -Chris > > -- > http://nondot.org/sabre/ > http://llvm.org/ > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20070506/63f992e2/attachment.html From resistor at mac.com Sun May 6 23:19:01 2007 From: resistor at mac.com (Owen Anderson) Date: Sun, 6 May 2007 23:19:01 -0500 Subject: [LLVMdev] 1 Week Before 2.0 Branch Creation In-Reply-To: <18edb2ad0705062035q79f56e4fw82f0f2b6714aa9fe@mail.gmail.com> References: <463B56EA.5060303@obbligato.org> <463CDC1F.2060907@obbligato.org> <010201c78f4d$c8f1ebe0$0200a8c0@AMD2500> <463CE464.9000400@obbligato.org> <20070506105530.7820C149125@blake.inputplus.co.uk> <18edb2ad0705062035q79f56e4fw82f0f2b6714aa9fe@mail.gmail.com> Message-ID: <3366036C-720A-4535-A1A1-DC938335D57E@mac.com> I'd definitely be interested in seeing this happen. If you get it working, I might be able to contribute a build slave as well. --Owen On May 6, 2007, at 10:35 PM, Chandler Carruth wrote: > I don't know if others would be interested as well, but I should be > able to set it up at least on one of my machines over the summer, > and on a continuing basis if its found useful. Should be at least > useful to me with the work I'll be doing on LLVM over the summer. > > (NB: a speedy x86-64 linux box currently) > > -Chandler > > On 5/6/07, Chris Lattner wrote: > On Sun, 6 May 2007, Ralph Corderoy wrote: > > Are you aware of buildbot? It's quite widely used and flexible. > > http://buildbot.sourceforge.net/ > > I'd suggest at least one machine given over to always building > whenever > > anything changes, and have the other nightly volunteers as now. > Using > > just nightly volunteers isn't great because breakage is noticed > too late > > and can affect too many people by then. > > That looks nifty. If someone wanted to set it up on their machine, we > could give it a try and see how it works. > > -Chris > > -- > http://nondot.org/sabre/ > http://llvm.org/ > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20070506/0854c245/attachment.html From christopher.lamb at gmail.com Mon May 7 00:20:58 2007 From: christopher.lamb at gmail.com (Christopher Lamb) Date: Mon, 7 May 2007 00:20:58 -0500 Subject: [LLVMdev] 1 Week Before 2.0 Branch Creation In-Reply-To: <3366036C-720A-4535-A1A1-DC938335D57E@mac.com> References: <463B56EA.5060303@obbligato.org> <463CDC1F.2060907@obbligato.org> <010201c78f4d$c8f1ebe0$0200a8c0@AMD2500> <463CE464.9000400@obbligato.org> <20070506105530.7820C149125@blake.inputplus.co.uk> <18edb2ad0705062035q79f56e4fw82f0f2b6714aa9fe@mail.gmail.com> <3366036C-720A-4535-A1A1-DC938335D57E@mac.com> Message-ID: Please see/reference PR1368 for previous discussion and to track work on such a facility. Thanks -- Chris On May 6, 2007, at 11:19 PM, Owen Anderson wrote: > I'd definitely be interested in seeing this happen. If you get it > working, I might be able to contribute a build slave as well. > > --Owen > > On May 6, 2007, at 10:35 PM, Chandler Carruth wrote: > >> I don't know if others would be interested as well, but I should >> be able to set it up at least on one of my machines over the >> summer, and on a continuing basis if its found useful. Should be >> at least useful to me with the work I'll be doing on LLVM over the >> summer. >> >> (NB: a speedy x86-64 linux box currently) >> >> -Chandler >> >> On 5/6/07, Chris Lattner wrote: >> On Sun, 6 May 2007, Ralph Corderoy wrote: >> > Are you aware of buildbot? It's quite widely used and flexible. >> > http://buildbot.sourceforge.net/ >> > I'd suggest at least one machine given over to always building >> whenever >> > anything changes, and have the other nightly volunteers as now. >> Using >> > just nightly volunteers isn't great because breakage is noticed >> too late >> > and can affect too many people by then. >> >> That looks nifty. If someone wanted to set it up on their >> machine, we >> could give it a try and see how it works. >> >> -Chris >> >> -- >> http://nondot.org/sabre/ >> http://llvm.org/ >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev -- Christopher Lamb -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20070507/8a4d7f10/attachment-0001.html From jeffc at jolt-lang.org Mon May 7 10:29:38 2007 From: jeffc at jolt-lang.org (Jeff Cohen) Date: Mon, 07 May 2007 08:29:38 -0700 Subject: [LLVMdev] LLVM-GCC Back In-Reply-To: <463DE12A.3010605@jolt-lang.org> References: <16e5fdf90705041701n175fa3e4xadfcbdbbc6111222@mail.gmail.com> <463C8A31.7040709@jolt-lang.org> <7D410BA6-1EE0-40F9-B59F-DCC931BB3F8E@gmail.com> <463CEBD2.5040604@jolt-lang.org> <463CEFBB.1080003@jolt-lang.org> <463DDC00.90202@jolt-lang.org> <463DE12A.3010605@jolt-lang.org> Message-ID: <463F45E2.9070905@jolt-lang.org> Jeff Cohen wrote: > And even if the mirror was promptly updated at 2am, it wouldn't have > mattered. The mirror got fatally out of sync with llvm less than an > hour later. There are still massive errors building llvm-gcc. > My nightly tester still can't build llvm-gcc. > And the Visual Studio build is massively broken too. I don't have time > to fix it today. It is now fixed. From tonic at nondot.org Mon May 7 12:23:14 2007 From: tonic at nondot.org (Tanya M. Lattner) Date: Mon, 7 May 2007 10:23:14 -0700 (PDT) Subject: [LLVMdev] LLVM-GCC Back In-Reply-To: <463F45E2.9070905@jolt-lang.org> References: <16e5fdf90705041701n175fa3e4xadfcbdbbc6111222@mail.gmail.com> <463C8A31.7040709@jolt-lang.org> <7D410BA6-1EE0-40F9-B59F-DCC931BB3F8E@gmail.com> <463CEBD2.5040604@jolt-lang.org> <463CEFBB.1080003@jolt-lang.org> <463DDC00.90202@jolt-lang.org> <463DE12A.3010605@jolt-lang.org> <463F45E2.9070905@jolt-lang.org> Message-ID: >> And even if the mirror was promptly updated at 2am, it wouldn't have >> mattered. The mirror got fatally out of sync with llvm less than an >> hour later. There are still massive errors building llvm-gcc. >> > > My nightly tester still can't build llvm-gcc. This is not very useful. Please file a PR and provide details on what errors you are getting and what platform. Someone will take a look at it then. -Tanya From tonic at nondot.org Mon May 7 12:28:39 2007 From: tonic at nondot.org (Tanya M. Lattner) Date: Mon, 7 May 2007 10:28:39 -0700 (PDT) Subject: [LLVMdev] 2.0 Release Branch TONIGHT 9PM PDT Message-ID: This is just a reminder that I will be creating the 2.0 release branch tonight at 9pm PDT (GMT-7). I'll send out email before and after branch creation. CVS commit access will not be allowed during this time. Thanks, Tanya From jeffc at jolt-lang.org Mon May 7 11:16:30 2007 From: jeffc at jolt-lang.org (Jeff Cohen) Date: Mon, 07 May 2007 09:16:30 -0700 Subject: [LLVMdev] LLVM-GCC Back In-Reply-To: References: <16e5fdf90705041701n175fa3e4xadfcbdbbc6111222@mail.gmail.com> <463C8A31.7040709@jolt-lang.org> <7D410BA6-1EE0-40F9-B59F-DCC931BB3F8E@gmail.com> <463CEBD2.5040604@jolt-lang.org> <463CEFBB.1080003@jolt-lang.org> <463DDC00.90202@jolt-lang.org> <463DE12A.3010605@jolt-lang.org> <463F45E2.9070905@jolt-lang.org> Message-ID: <463F50DE.90700@jolt-lang.org> Tanya M. Lattner wrote: > >>> And even if the mirror was promptly updated at 2am, it wouldn't have >>> mattered. The mirror got fatally out of sync with llvm less than an >>> hour later. There are still massive errors building llvm-gcc. >>> >> >> My nightly tester still can't build llvm-gcc. > > This is not very useful. Please file a PR and provide details on what > errors you are getting and what platform. Someone will take a look at > it then. > > -Tanya It can't build it because the API keeps changing faster than the mirror can keep up. It would be more useful to keep the API stable, as the freeze is right around the corner, than to file a PR. Or I can simply stop running the nightly tester until the conversion to svn occurs and the mirror is history. In fact, that is what I'll do. It is not worth the hassle. From angray at beeb.net Mon May 7 15:12:07 2007 From: angray at beeb.net (Aaron Gray) Date: Mon, 7 May 2007 21:12:07 +0100 Subject: [LLVMdev] goodbye bytecode, hello bitcode References: Message-ID: <003601c790e3$fe6953c0$0200a8c0@AMD2500> > Please let me know if you run into any problems. Documentation of the > file format is in the works. The bytecode support code is still in the > tree, but isn't being built. Assuming no major problems, I will remove > the old code tomorrow. I am getting a missing 'lib/Archive' directory when making from an updated CVS. Aaron From rspencer at reidspencer.com Mon May 7 15:45:05 2007 From: rspencer at reidspencer.com (Reid Spencer) Date: Mon, 07 May 2007 13:45:05 -0700 Subject: [LLVMdev] goodbye bytecode, hello bitcode In-Reply-To: <003601c790e3$fe6953c0$0200a8c0@AMD2500> References: <003601c790e3$fe6953c0$0200a8c0@AMD2500> Message-ID: <1178570705.18852.85.camel@bashful.x10sys.com> On Mon, 2007-05-07 at 21:12 +0100, Aaron Gray wrote: > > Please let me know if you run into any problems. Documentation of the > > file format is in the works. The bytecode support code is still in the > > tree, but isn't being built. Assuming no major problems, I will remove > > the old code tomorrow. > > I am getting a missing 'lib/Archive' directory when making from an updated > CVS. When doing your update, use these options: cvs update -ARPd REid. > > Aaron > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From gordonhenriksen at mac.com Mon May 7 15:48:47 2007 From: gordonhenriksen at mac.com (Gordon Henriksen) Date: Mon, 7 May 2007 16:48:47 -0400 Subject: [LLVMdev] goodbye bytecode, hello bitcode In-Reply-To: <003601c790e3$fe6953c0$0200a8c0@AMD2500> References: <003601c790e3$fe6953c0$0200a8c0@AMD2500> Message-ID: On 2007-05-07, at 16:12, Aaron Gray wrote: >> Please let me know if you run into any problems. Documentation of >> the >> file format is in the works. The bytecode support code is still >> in the >> tree, but isn't being built. Assuming no major problems, I will >> remove >> the old code tomorrow. > > I am getting a missing 'lib/Archive' directory when making from an > updated > CVS. Did you use the -d flag when you performed a cvs update? If not, it won't discover new directories in the repository. ? Gordon From angray at beeb.net Mon May 7 16:09:49 2007 From: angray at beeb.net (Aaron Gray) Date: Mon, 7 May 2007 22:09:49 +0100 Subject: [LLVMdev] goodbye bytecode, hello bitcode References: <003601c790e3$fe6953c0$0200a8c0@AMD2500> <1178570705.18852.85.camel@bashful.x10sys.com> Message-ID: <006801c790ec$0ce89840$0200a8c0@AMD2500> > On Mon, 2007-05-07 at 21:12 +0100, Aaron Gray wrote: >> > Please let me know if you run into any problems. Documentation of the >> > file format is in the works. The bytecode support code is still in the >> > tree, but isn't being built. Assuming no major problems, I will remove >> > the old code tomorrow. >> >> I am getting a missing 'lib/Archive' directory when making from an >> updated >> CVS. > > When doing your update, use these options: > > cvs update -ARPd Thanks Reid. I should have squatted up on CVS a bit better. Aaron From tonic at nondot.org Mon May 7 23:20:09 2007 From: tonic at nondot.org (Tanya M. Lattner) Date: Mon, 7 May 2007 21:20:09 -0700 (PDT) Subject: [LLVMdev] 2.0 Branch Creation - NOW Message-ID: I'm creating the 2.0 release branch. Users with cvs commit access, please refrain from checking anything in. I will send email out once I have finished. -Tanya From lefever at crhc.uiuc.edu Mon May 7 23:45:50 2007 From: lefever at crhc.uiuc.edu (Ryan M. Lefever) Date: Mon, 07 May 2007 23:45:50 -0500 Subject: [LLVMdev] llvm-ld support of native libraries Message-ID: <4640007E.1040006@crhc.uiuc.edu> What is the current status of llvm-ld's support of native libraries? I have a bytecode file that needs to link against librt.so. So, I ran: llvm-ld -native -o x.exe x.bc -L/usr/lib64 -lrt and I get the following error: /tmp/ccB7DGu1.o(.text+0x1a3): In function `main': : undefined reference to `clock_gettime' /tmp/ccB7DGu1.o(.text+0x6d8): In function `main': : undefined reference to `clock_gettime' collect2: ld returned 1 exit status Is that error occurring because llvm-ld does not support native libraries. I am able to use llc to turn x.bc into native assembly and gcc to link the natively assembly against librt.so to get an executable, but I was going to use the llvm native backend if possible. Regards, Ryan From tonic at nondot.org Tue May 8 00:02:11 2007 From: tonic at nondot.org (Tanya M. Lattner) Date: Mon, 7 May 2007 22:02:11 -0700 (PDT) Subject: [LLVMdev] 2.0 Branch Creation - FINISHED! In-Reply-To: References: Message-ID: > I'm creating the 2.0 release branch. Users with cvs commit access, please > refrain from checking anything in. I will send email out once I have > finished. I am finished creating the branch. CVS is open again. I will send out more details about the release and release branch in a bit. Please do not check in changes into the relase branch until I send out email detailing the procedure. Thanks! -Tanya From rspencer at reidspencer.com Tue May 8 00:10:12 2007 From: rspencer at reidspencer.com (Reid Spencer) Date: Mon, 07 May 2007 22:10:12 -0700 Subject: [LLVMdev] llvm-ld support of native libraries In-Reply-To: <4640007E.1040006@crhc.uiuc.edu> References: <4640007E.1040006@crhc.uiuc.edu> Message-ID: <1178601012.18852.143.camel@bashful.x10sys.com> On Mon, 2007-05-07 at 23:45 -0500, Ryan M. Lefever wrote: > What is the current status of llvm-ld's support of native libraries? It should be working. We've fixed some issues with correct detection of object/archive/shared object files in the last few weeks. > I > have a bytecode file that needs to link against librt.so. So, I ran: > > llvm-ld -native -o x.exe x.bc -L/usr/lib64 -lrt > > and I get the following error: > > /tmp/ccB7DGu1.o(.text+0x1a3): In function `main': > : undefined reference to `clock_gettime' > /tmp/ccB7DGu1.o(.text+0x6d8): In function `main': > : undefined reference to `clock_gettime' > collect2: ld returned 1 exit status Have you verified that librt.so is in /usr/lib64 and that it contains clock_gettime? This looks like a standard undefined reference message meaning you haven't supplied sufficient arguments to llvm-ld to link the program. Does a similar command line with gcc work? > > Is that error occurring because llvm-ld does not support native > libraries. No. Its occurring because the clock_gettime symbol can't be found. Note that llvm-ld invokes the native linker (via gcc) to do the actual native linking. > I am able to use llc to turn x.bc into native assembly and > gcc to link the natively assembly against librt.so to get an executable, > but I was going to use the llvm native backend if possible. That's another way to do it, but the way you described above should work as well and should, in fact, do the same thing. That is, when you link as given above, llvm-ld will: 1. convert x.bc into x.s via llc 2. assemble llc using gcc (which punts it to gas) 3. link using gcc with something like gcc -o x.exe x.o -L/usr/lib64 -lrt Reid. > > Regards, > Ryan > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From fbrandne at mail.tuwien.ac.at Tue May 8 03:49:49 2007 From: fbrandne at mail.tuwien.ac.at (Florian Brandner) Date: Tue, 08 May 2007 10:49:49 +0200 Subject: [LLVMdev] llvm-test make problems In-Reply-To: References: <463B2921.8040405@mail.tuwien.ac.at> <463B3534.4060806@mail.tuwien.ac.at> Message-ID: <464039AD.6080604@mail.tuwien.ac.at> Chris Lattner wrote: > Is it just this one test that doesn't work, or do no tests work? If no > tests work, you probably need to rerun configure in llvm-test. Make > sure that llvm-gcc is in your path and detected by the configure script. i found the problem. we have a script that builds llvm and llvm-gcc and configures llvm-test. this script had a little flaw so that LLVMGCCDIR was not set properly. as a result, llvm-gcc, opt, etc. where found automatically, but cc1 and cc1plus not. reconfiguring llvm and llvm-test did work in the end. cc1 and cc1plus are required by the rules in Makefile.tests, e.g.: Output/%.bc: %.c $(LCC1) Output/.dir $(INCLUDES) -$(LLVMGCC) $(CPPFLAGS) $(LCCFLAGS) $(TARGET_FLAGS) -O0 -c $< \ -o $@ -emit-llvm -$(call UPGRADE_LL,$@) should`t LLVMGCC also be a prerequisite here? i found in the mailing list archive, that someone else had a similar problem (without a solution). so it seems this kind of error occurs from time to time. how about adding rules like these to the makefiles: $(LCC1XX): @echo "Missing tool LLC1XX: $(LCC1XX)." && false $(LCC1): @echo "Missing tool LLC1: $(LCC1)." && false $(LLVMAS): @echo "Missing tool LLVMAS: $(LLVMAS)." && false this would report missing tools automatically. if you want i could prepare a patch? cheers, florian From napi at axiomsol.com Tue May 8 11:13:34 2007 From: napi at axiomsol.com (Mohd-Hanafiah Abdullah) Date: Wed, 09 May 2007 00:13:34 +0800 Subject: [LLVMdev] C back-end differences In-Reply-To: <4561D985.3050402@cs.uiuc.edu> References: <1162701613.22790.15.camel@mobile> <1162703179.11568.314.camel@bashful.x10sys.com> <1162722616.13236.2.camel@mobile> <1163738967.6023.6.camel@mobile.axiomsol.com> <1163752943.11597.16.camel@mobile.axiomsol.com> <455DD330.1000706@cs.uiuc.edu> <1163814113.6303.4.camel@mobile.axiomsol.com> <4561D985.3050402@cs.uiuc.edu> Message-ID: <1178640814.5737.3.camel@mobile> How does the C back-end of LLVM differ from the one in gcc2c developed by SUN several years ago? Thanks. Napi From angray at beeb.net Tue May 8 13:49:19 2007 From: angray at beeb.net (Aaron Gray) Date: Tue, 8 May 2007 19:49:19 +0100 Subject: [LLVMdev] Problems with 'make check' Message-ID: <024801c791a1$96ffd7e0$0200a8c0@AMD2500> I am getting problems with 'make check' on Linux x86. Several instances of 'couldn't execute "-emit-llvm": no such file or directory' :- FAIL: /usr/src/llvm/test/CodeGen/CBackend/2007-01-06-Signless.c Failed with posix(ENOENT,no such file or directory) at line 1 while running: -emit-llvm -S /usr/src/llvm/test/CodeGen/CBackend/2007-01-06-Signless.c -o - | llvm-as | llc -march=c | grep {(unsigned short} couldn't execute "-emit-llvm": no such file or directory 'make check' output attached. AFAICT there is nothing different in my setup, these tests were working fine before. Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20070508/8e8dd0fc/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: make_check.out Type: application/octet-stream Size: 7723 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20070508/8e8dd0fc/attachment.obj From isanbard at gmail.com Tue May 8 13:58:16 2007 From: isanbard at gmail.com (Bill) Date: Tue, 8 May 2007 11:58:16 -0700 Subject: [LLVMdev] C back-end differences In-Reply-To: <1178640814.5737.3.camel@mobile> References: <1162701613.22790.15.camel@mobile> <1163738967.6023.6.camel@mobile.axiomsol.com> <1163752943.11597.16.camel@mobile.axiomsol.com> <455DD330.1000706@cs.uiuc.edu> <1163814113.6303.4.camel@mobile.axiomsol.com> <4561D985.3050402@cs.uiuc.edu> <1178640814.5737.3.camel@mobile> Message-ID: <16e5fdf90705081158oaca8a20n6f9faf3f218547fd@mail.gmail.com> On 5/8/07, Mohd-Hanafiah Abdullah wrote: > How does the C back-end of LLVM differ from the one in gcc2c developed > by SUN several years ago? > Hi Napi, For one, it converts LLVM's bytecode to C instead of GCC's RTL. It's also under a different license. As far as code quality, I don't believe it's been compared. -bw From tonic at nondot.org Tue May 8 14:08:24 2007 From: tonic at nondot.org (Tanya M. Lattner) Date: Tue, 8 May 2007 12:08:24 -0700 (PDT) Subject: [LLVMdev] Problems with 'make check' In-Reply-To: <024801c791a1$96ffd7e0$0200a8c0@AMD2500> References: <024801c791a1$96ffd7e0$0200a8c0@AMD2500> Message-ID: > Several instances of 'couldn't execute "-emit-llvm": no such file or directory' :- > > FAIL: /usr/src/llvm/test/CodeGen/CBackend/2007-01-06-Signless.c > Failed with posix(ENOENT,no such file or directory) at line 1 > while running: -emit-llvm -S /usr/src/llvm/test/CodeGen/CBackend/2007-01-06-Signless.c -o - | llvm-as | llc -march=c | grep {(unsigned short} > couldn't execute "-emit-llvm": no such file or directory Looks like it couldn't find llvm-gcc. -Tanya > > 'make check' output attached. > > AFAICT there is nothing different in my setup, these tests were working fine before. > > Aaron > From angray at beeb.net Tue May 8 14:01:20 2007 From: angray at beeb.net (Aaron Gray) Date: Tue, 8 May 2007 20:01:20 +0100 Subject: [LLVMdev] Problems with 'make check' References: <024801c791a1$96ffd7e0$0200a8c0@AMD2500> Message-ID: <024d01c791a3$44976de0$0200a8c0@AMD2500> >> Several instances of 'couldn't execute "-emit-llvm": no such file or >> directory' :- >> >> FAIL: /usr/src/llvm/test/CodeGen/CBackend/2007-01-06-Signless.c >> Failed with posix(ENOENT,no such file or directory) at line 1 >> while running: -emit-llvm -S >> /usr/src/llvm/test/CodeGen/CBackend/2007-01-06-Signless.c -o - | llvm-as >> | llc -march=c | grep {(unsigned short} >> couldn't execute "-emit-llvm": no such file or directory > > Looks like it couldn't find llvm-gcc. Its on the path. Aaron From tonic at nondot.org Tue May 8 14:21:32 2007 From: tonic at nondot.org (Tanya M. Lattner) Date: Tue, 8 May 2007 12:21:32 -0700 (PDT) Subject: [LLVMdev] Problems with 'make check' In-Reply-To: <024d01c791a3$44976de0$0200a8c0@AMD2500> References: <024801c791a1$96ffd7e0$0200a8c0@AMD2500> <024d01c791a3$44976de0$0200a8c0@AMD2500> Message-ID: >>> FAIL: /usr/src/llvm/test/CodeGen/CBackend/2007-01-06-Signless.c >>> Failed with posix(ENOENT,no such file or directory) at line 1 >>> while running: -emit-llvm -S >>> /usr/src/llvm/test/CodeGen/CBackend/2007-01-06-Signless.c -o - | llvm-as >>> | llc -march=c | grep {(unsigned short} >>> couldn't execute "-emit-llvm": no such file or directory >> >> Looks like it couldn't find llvm-gcc. > > Its on the path. Is it set in site.exp? -Tanya > > Aaron > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From angray at beeb.net Tue May 8 14:36:32 2007 From: angray at beeb.net (Aaron Gray) Date: Tue, 8 May 2007 20:36:32 +0100 Subject: [LLVMdev] Problems with 'make check' References: <024801c791a1$96ffd7e0$0200a8c0@AMD2500><024d01c791a3$44976de0$0200a8c0@AMD2500> Message-ID: <027101c791a8$35c16af0$0200a8c0@AMD2500> >>> Looks like it couldn't find llvm-gcc. >> >> Its on the path. > > Is it set in site.exp? Thats it, great. Should I be testing the 2.0 candiate release from CVS or are you releasing .tar.gz's ? Thanks alot, Aaron From tonic at nondot.org Tue May 8 15:00:38 2007 From: tonic at nondot.org (Tanya M. Lattner) Date: Tue, 8 May 2007 13:00:38 -0700 (PDT) Subject: [LLVMdev] Problems with 'make check' In-Reply-To: <027101c791a8$35c16af0$0200a8c0@AMD2500> References: <024801c791a1$96ffd7e0$0200a8c0@AMD2500><024d01c791a3$44976de0$0200a8c0@AMD2500> <027101c791a8$35c16af0$0200a8c0@AMD2500> Message-ID: >> Is it set in site.exp? > > Thats it, great. > > Should I be testing the 2.0 candiate release from CVS or are you releasing > .tar.gz's ? I'll be sending out more instructions tonight, but I'll be sending out tarballs but people can test from the branch too. I need to do some more merging into the branch tonight. -Tanya From rspencer at reidspencer.com Tue May 8 15:04:19 2007 From: rspencer at reidspencer.com (Reid Spencer) Date: Tue, 08 May 2007 20:04:19 +0000 Subject: [LLVMdev] Problems with 'make check' In-Reply-To: <027101c791a8$35c16af0$0200a8c0@AMD2500> References: <024801c791a1$96ffd7e0$0200a8c0@AMD2500> <024d01c791a3$44976de0$0200a8c0@AMD2500> <027101c791a8$35c16af0$0200a8c0@AMD2500> Message-ID: <1178654659.18852.164.camel@bashful.x10sys.com> On Tue, 2007-05-08 at 20:36 +0100, Aaron Gray wrote: > >>> Looks like it couldn't find llvm-gcc. > >> > >> Its on the path. > > > > Is it set in site.exp? > > Thats it, great. Aaron, Please note that the path is (purposefully) not used to locate test executables. Many of us have many LLVM environments and using the path leads to confusion. What the makefile is looking for is the LLVMGCC variable to be set. It wasn't so when substituted you get a null string which leads to attempting to execute "-emit-llvm" (the first argument after the null program name). You can resolve this by using the --with-llvmgccdir option when configuring llvm. Reid. > > Should I be testing the 2.0 candiate release from CVS or are you releasing > .tar.gz's ? > > Thanks alot, > > Aaron > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From angray at beeb.net Tue May 8 15:45:56 2007 From: angray at beeb.net (Aaron Gray) Date: Tue, 8 May 2007 21:45:56 +0100 Subject: [LLVMdev] Problems with 'make check' References: <024801c791a1$96ffd7e0$0200a8c0@AMD2500><024d01c791a3$44976de0$0200a8c0@AMD2500><027101c791a8$35c16af0$0200a8c0@AMD2500> <1178654659.18852.164.camel@bashful.x10sys.com> Message-ID: <029701c791b1$e0fe7580$0200a8c0@AMD2500> > Please note that the path is (purposefully) not used to locate test > executables. Many of us have many LLVM environments and using the path > leads to confusion. What the makefile is looking for is the LLVMGCC > variable to be set. It wasn't so when substituted you get a null string > which leads to attempting to execute "-emit-llvm" (the first argument > after the null program name). You can resolve this by using the > --with-llvmgccdir option when configuring llvm. Right I will amend my proceedure. Its odd as it has worked fine uptil now. Thanks, Aaron From bsalamat at uci.edu Tue May 8 20:40:18 2007 From: bsalamat at uci.edu (Babak Salamat) Date: Tue, 8 May 2007 18:40:18 -0700 Subject: [LLVMdev] Compiling glibc on Linux Message-ID: <0C52DA88-E2EC-43D4-ADE8-C4A6B4C82522@uci.edu> Hi, I am trying to compile glibc on Linux using llvm. I need to do this for a research project. The problem is that llvmc doesn't work, and I guess I have to set CC=llvmc to get the glic compiled. For some reason llvmc complains that it cannot find %llvmcc1%. I have this problem both on my Mac and my Linux system. Other tools that I have tested including llvm-gcc work without any problem. First, I appreciate it if you let me know what can cause this problem and second, tell me if you think I have any chance to compile glibc using LLVM. Thank you, Babak --------------------------------------------------------------- Babak Salamat PhD Student Department of Computer Science School of Information and Computer Sciences University of California, Irvine email: bsalamat at uci.edu web: www.ics.uci.edu/~bsalamat --------------------------------------------------------------- From rspencer at reidspencer.com Tue May 8 21:33:40 2007 From: rspencer at reidspencer.com (Reid Spencer) Date: Wed, 09 May 2007 02:33:40 +0000 Subject: [LLVMdev] Compiling glibc on Linux In-Reply-To: <0C52DA88-E2EC-43D4-ADE8-C4A6B4C82522@uci.edu> References: <0C52DA88-E2EC-43D4-ADE8-C4A6B4C82522@uci.edu> Message-ID: <1178678020.18852.269.camel@bashful.x10sys.com> Babak, As its manual page (http://llvm.org/docs/CommandGuide/html/llvmc.html) states, llvmc is an experimental tool: llvmc is considered an experimental LLVM tool because it has these deficiencies: Poor configuration support The support for configuring new languages, etc. is weak. There are many command line configurations that cannot be achieved with the current support. Furthermore the grammar is cumbersome for configuration files. Please see http://llvm.org/PR686 for further details. That said, you should be able to get it to work with llvm-gcc. Did you build llvm-gcc? Did you check the paths in the "c" config file? Did you install the config files? All of these things need to be done in order for the standard config file to work. Reid. On Tue, 2007-05-08 at 18:40 -0700, Babak Salamat wrote: > Hi, > > I am trying to compile glibc on Linux using llvm. I need to do this > for a research project. > The problem is that llvmc doesn't work, and I guess I have to set > CC=llvmc to get the glic compiled. For some reason llvmc complains > that it cannot find %llvmcc1%. I have this problem both on my Mac and > my Linux system. Other tools that I have tested including llvm-gcc > work without any problem. > First, I appreciate it if you let me know what can cause this problem > and second, tell me if you think I have any chance to compile glibc > using LLVM. > > Thank you, > Babak > > --------------------------------------------------------------- > Babak Salamat > PhD Student > Department of Computer Science > School of Information and Computer Sciences > University of California, Irvine > email: bsalamat at uci.edu > web: www.ics.uci.edu/~bsalamat > --------------------------------------------------------------- > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From tonic at nondot.org Tue May 8 23:06:46 2007 From: tonic at nondot.org (Tanya M. Lattner) Date: Tue, 8 May 2007 21:06:46 -0700 (PDT) Subject: [LLVMdev] LLVM Developers Meeting - Dinner (Response needed) Message-ID: LLVM Developer Meeting Attendees, I need to get a count of the people planning to stay after the meeting for dinner. If we have a large enough group, we may need to make special arrangements. Attendees will have to pay for their own dinner, but we can get reservations or possibly reserve a banquet room. So please email me by May 11th, if you plan to go to dinner. Thanks, Tanya Lattner From resistor at mac.com Tue May 8 23:46:06 2007 From: resistor at mac.com (Owen Anderson) Date: Tue, 8 May 2007 23:46:06 -0500 Subject: [LLVMdev] LLVM Developers Meeting - Dinner (Response needed) In-Reply-To: References: Message-ID: I'd like to attend! --Owen Anderson On May 8, 2007, at 11:06 PM, Tanya M. Lattner wrote: > LLVM Developer Meeting Attendees, > > I need to get a count of the people planning to stay after the > meeting for > dinner. If we have a large enough group, we may need to make special > arrangements. > > Attendees will have to pay for their own dinner, but we can get > reservations or possibly reserve a banquet room. > > So please email me by May 11th, if you plan to go to dinner. > > Thanks, > Tanya Lattner > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From napi at axiomsol.com Wed May 9 00:05:58 2007 From: napi at axiomsol.com (Mohd-Hanafiah Abdullah) Date: Wed, 09 May 2007 13:05:58 +0800 Subject: [LLVMdev] C back-end differences In-Reply-To: <16e5fdf90705081158oaca8a20n6f9faf3f218547fd@mail.gmail.com> References: <1162701613.22790.15.camel@mobile> <1163738967.6023.6.camel@mobile.axiomsol.com> <1163752943.11597.16.camel@mobile.axiomsol.com> <455DD330.1000706@cs.uiuc.edu> <1163814113.6303.4.camel@mobile.axiomsol.com> <4561D985.3050402@cs.uiuc.edu> <1178640814.5737.3.camel@mobile> <16e5fdf90705081158oaca8a20n6f9faf3f218547fd@mail.gmail.com> Message-ID: <1178687158.6190.11.camel@mobile> On Tue, 2007-05-08 at 11:58 -0700, Bill wrote: > On 5/8/07, Mohd-Hanafiah Abdullah wrote: > > How does the C back-end of LLVM differ from the one in gcc2c developed > > by SUN several years ago? > > > Hi Napi, > > For one, it converts LLVM's bytecode to C instead of GCC's RTL. It's > also under a different license. Hi Bill: Would it be easier to convert from LLVM's bytecode to C as opposed to from RTL? What about the readability of the produced C code. I would think since RTL maintains a structure that is directly inherited from the high-level language structure it would be less difficult to turn it into some C code that is relatively more readable, as compared to synthesizing C code from the low-level bytecode. I stand corrected. Thanks. Napi From tonic at nondot.org Wed May 9 00:17:41 2007 From: tonic at nondot.org (Tanya M. Lattner) Date: Tue, 8 May 2007 22:17:41 -0700 (PDT) Subject: [LLVMdev] 2.0 Release Process Message-ID: The release branch has been created and the llvm-gcc mirror updated (thanks Bill!). I will be doing some preliminary testing before I request the help of the community to test the release. During this time, I ask that developers only commit documentation changes to the release branch and email the list with any bug fixes that need to be merged into the release branch. Bug fixes have to be approved by the various owners of the different parts of llvm. Here is the schedule: May 7th - Release branch created. Developers should begin reviewing all documentation. May 14th - Tar balls and binaries are released for general testing. I'll also need volunteers to create additional llvm-gcc binaries that I have not provided. May 18th - All documentation changes should have been merged into the release branch. May 21st - Release! Chris will also be sending out the release notes and release announcement for review in the next week. As a reminder, if you wish to check out the release branch use the following commands (also see GettingStartedGuide.html): cvs -d co -r release_20 llvm cvs -d co -r release_20 llvm-test svn co svn://anonsvn.opensource.apple.com/svn/llvm/tags/release-2.0 dst-directory If you have any questions, please let me know. Thanks, Tanya From isanbard at gmail.com Wed May 9 00:45:25 2007 From: isanbard at gmail.com (Bill Wendling) Date: Tue, 8 May 2007 22:45:25 -0700 Subject: [LLVMdev] C back-end differences In-Reply-To: <1178687158.6190.11.camel@mobile> References: <1162701613.22790.15.camel@mobile> <1163738967.6023.6.camel@mobile.axiomsol.com> <1163752943.11597.16.camel@mobile.axiomsol.com> <455DD330.1000706@cs.uiuc.edu> <1163814113.6303.4.camel@mobile.axiomsol.com> <4561D985.3050402@cs.uiuc.edu> <1178640814.5737.3.camel@mobile> <16e5fdf90705081158oaca8a20n6f9faf3f218547fd@mail.gmail.com> <1178687158.6190.11.camel@mobile> Message-ID: <8C785471-61D9-4FAA-8A03-6E708ED859D3@gmail.com> On May 8, 2007, at 10:05 PM, Mohd-Hanafiah Abdullah wrote: > On Tue, 2007-05-08 at 11:58 -0700, Bill wrote: >> On 5/8/07, Mohd-Hanafiah Abdullah wrote: >>> How does the C back-end of LLVM differ from the one in gcc2c >>> developed >>> by SUN several years ago? >>> >> Hi Napi, >> >> For one, it converts LLVM's bytecode to C instead of GCC's RTL. It's >> also under a different license. > > Hi Bill: > > Would it be easier to convert from LLVM's bytecode to C as opposed to > from RTL? What about the readability of the produced C code. I would > think since RTL maintains a structure that is directly inherited from > the high-level language structure it would be less difficult to > turn it > into some C code that is relatively more readable, as compared to > synthesizing C code from the low-level bytecode. I stand corrected. > Hi Napi, Considering that LLVM already has a C backend, then it's easier to generate it from the LLVM bytecode. :-) LLVM's intermediate representation of the program (the bytecode) is also derived directly from the high-level language. When it gets to the C backend part, it simply has had transformations done on it. I don't believe that the C backend was made for readability. In fact, because LLVM is in SSA form, it uses many temporary variables and loses a lot of the information about what the original variable's name was. The best way to get a feel for how it is is to write a program and generate the C code for it with the LLVM backend. (See the llc tool for information on this.) Though, this begs the question of why you want to use something which converts it to C instead of just using one of the target backends to generate native code. -bw From bsalamat at uci.edu Wed May 9 01:19:16 2007 From: bsalamat at uci.edu (Babak Salamat) Date: Tue, 8 May 2007 23:19:16 -0700 Subject: [LLVMdev] Compiling glibc on Linux In-Reply-To: <1178678020.18852.269.camel@bashful.x10sys.com> References: <0C52DA88-E2EC-43D4-ADE8-C4A6B4C82522@uci.edu> <1178678020.18852.269.camel@bashful.x10sys.com> Message-ID: Reid, Thank you for your quick reply. Yes, I have built and installed llvm-gcc and "llvm-gcc --print-prog- name=cc1" return the correct path for cc1, so I assume its path is set correctly in the config files, but I haven't installed config files separately. Do I need to do that? Is there any documentation about it? Thank you again, Babak On May 8, 2007, at 7:33 PM, Reid Spencer wrote: > Babak, > > As its manual page (http://llvm.org/docs/CommandGuide/html/llvmc.html) > states, llvmc is an experimental tool: > > llvmc is considered an experimental LLVM tool because it has these > deficiencies: > > Poor configuration support > The support for configuring new languages, etc. is weak. There > are many command line configurations that cannot be achieved > with the current support. Furthermore the grammar is > cumbersome > for configuration files. Please see http://llvm.org/PR686 for > further details. > > That said, you should be able to get it to work with llvm-gcc. > > Did you build llvm-gcc? Did you check the paths in the "c" config > file? > Did you install the config files? > > All of these things need to be done in order for the standard config > file to work. > > Reid. > > On Tue, 2007-05-08 at 18:40 -0700, Babak Salamat wrote: >> Hi, >> >> I am trying to compile glibc on Linux using llvm. I need to do this >> for a research project. >> The problem is that llvmc doesn't work, and I guess I have to set >> CC=llvmc to get the glic compiled. For some reason llvmc complains >> that it cannot find %llvmcc1%. I have this problem both on my Mac and >> my Linux system. Other tools that I have tested including llvm-gcc >> work without any problem. >> First, I appreciate it if you let me know what can cause this problem >> and second, tell me if you think I have any chance to compile glibc >> using LLVM. >> >> Thank you, >> Babak >> >> --------------------------------------------------------------- >> Babak Salamat >> PhD Student >> Department of Computer Science >> School of Information and Computer Sciences >> University of California, Irvine >> email: bsalamat at uci.edu >> web: www.ics.uci.edu/~bsalamat >> --------------------------------------------------------------- >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From sabre at nondot.org Wed May 9 01:33:43 2007 From: sabre at nondot.org (Chris Lattner) Date: Tue, 8 May 2007 23:33:43 -0700 (PDT) Subject: [LLVMdev] Compiling glibc on Linux In-Reply-To: References: <0C52DA88-E2EC-43D4-ADE8-C4A6B4C82522@uci.edu> <1178678020.18852.269.camel@bashful.x10sys.com> Message-ID: On Tue, 8 May 2007, Babak Salamat wrote: > Yes, I have built and installed llvm-gcc and "llvm-gcc --print-prog- > name=cc1" return the correct path for cc1, so I assume its path is > set correctly in the config files, but I haven't installed config > files separately. Do I need to do that? Is there any documentation > about it? I'd strongly suggest just building with CC=llvm-gcc CXX=llvm-g++. llvmc is extremely experimental and has not seen wide use. -Chris > On May 8, 2007, at 7:33 PM, Reid Spencer wrote: > >> Babak, >> >> As its manual page (http://llvm.org/docs/CommandGuide/html/llvmc.html) >> states, llvmc is an experimental tool: >> >> llvmc is considered an experimental LLVM tool because it has these >> deficiencies: >> >> Poor configuration support >> The support for configuring new languages, etc. is weak. There >> are many command line configurations that cannot be achieved >> with the current support. Furthermore the grammar is >> cumbersome >> for configuration files. Please see http://llvm.org/PR686 for >> further details. >> >> That said, you should be able to get it to work with llvm-gcc. >> >> Did you build llvm-gcc? Did you check the paths in the "c" config >> file? >> Did you install the config files? >> >> All of these things need to be done in order for the standard config >> file to work. >> >> Reid. >> >> On Tue, 2007-05-08 at 18:40 -0700, Babak Salamat wrote: >>> Hi, >>> >>> I am trying to compile glibc on Linux using llvm. I need to do this >>> for a research project. >>> The problem is that llvmc doesn't work, and I guess I have to set >>> CC=llvmc to get the glic compiled. For some reason llvmc complains >>> that it cannot find %llvmcc1%. I have this problem both on my Mac and >>> my Linux system. Other tools that I have tested including llvm-gcc >>> work without any problem. >>> First, I appreciate it if you let me know what can cause this problem >>> and second, tell me if you think I have any chance to compile glibc >>> using LLVM. >>> >>> Thank you, >>> Babak >>> >>> --------------------------------------------------------------- >>> Babak Salamat >>> PhD Student >>> Department of Computer Science >>> School of Information and Computer Sciences >>> University of California, Irvine >>> email: bsalamat at uci.edu >>> web: www.ics.uci.edu/~bsalamat >>> --------------------------------------------------------------- >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > -Chris -- http://nondot.org/sabre/ http://llvm.org/ From bsalamat at uci.edu Wed May 9 02:08:29 2007 From: bsalamat at uci.edu (Babak Salamat) Date: Wed, 9 May 2007 00:08:29 -0700 Subject: [LLVMdev] Compiling glibc on Linux In-Reply-To: References: <0C52DA88-E2EC-43D4-ADE8-C4A6B4C82522@uci.edu> <1178678020.18852.269.camel@bashful.x10sys.com> Message-ID: Thank you Chris. Actually, I have changed the stack organization in the "llc" source codes for x86 target. Thus, I need libraries compiled with the new stack organization. If I use llvm-gcc (and apparently also llvmc), llc will not be invoked. I was hoping that llvmc would call llvm-gcc to compile to bc file and then call llc to compile to native assembly, but apparently this doesn't happen. Do you know of any possible ways to involve llc in compilation of libraries? --Babak On May 8, 2007, at 11:33 PM, Chris Lattner wrote: > On Tue, 8 May 2007, Babak Salamat wrote: >> Yes, I have built and installed llvm-gcc and "llvm-gcc --print-prog- >> name=cc1" return the correct path for cc1, so I assume its path is >> set correctly in the config files, but I haven't installed config >> files separately. Do I need to do that? Is there any documentation >> about it? > > I'd strongly suggest just building with CC=llvm-gcc CXX=llvm-g++. > > llvmc is extremely experimental and has not seen wide use. > > -Chris > >> On May 8, 2007, at 7:33 PM, Reid Spencer wrote: >> >>> Babak, >>> >>> As its manual page (http://llvm.org/docs/CommandGuide/html/ >>> llvmc.html) >>> states, llvmc is an experimental tool: >>> >>> llvmc is considered an experimental LLVM tool because it has these >>> deficiencies: >>> >>> Poor configuration support >>> The support for configuring new languages, etc. is weak. >>> There >>> are many command line configurations that cannot be achieved >>> with the current support. Furthermore the grammar is >>> cumbersome >>> for configuration files. Please see http://llvm.org/PR686 >>> for >>> further details. >>> >>> That said, you should be able to get it to work with llvm-gcc. >>> >>> Did you build llvm-gcc? Did you check the paths in the "c" config >>> file? >>> Did you install the config files? >>> >>> All of these things need to be done in order for the standard config >>> file to work. >>> >>> Reid. >>> >>> On Tue, 2007-05-08 at 18:40 -0700, Babak Salamat wrote: >>>> Hi, >>>> >>>> I am trying to compile glibc on Linux using llvm. I need to do this >>>> for a research project. >>>> The problem is that llvmc doesn't work, and I guess I have to set >>>> CC=llvmc to get the glic compiled. For some reason llvmc complains >>>> that it cannot find %llvmcc1%. I have this problem both on my >>>> Mac and >>>> my Linux system. Other tools that I have tested including llvm-gcc >>>> work without any problem. >>>> First, I appreciate it if you let me know what can cause this >>>> problem >>>> and second, tell me if you think I have any chance to compile glibc >>>> using LLVM. >>>> >>>> Thank you, >>>> Babak >>>> >>>> --------------------------------------------------------------- >>>> Babak Salamat >>>> PhD Student >>>> Department of Computer Science >>>> School of Information and Computer Sciences >>>> University of California, Irvine >>>> email: bsalamat at uci.edu >>>> web: www.ics.uci.edu/~bsalamat >>>> --------------------------------------------------------------- >>>> >>>> _______________________________________________ >>>> LLVM Developers mailing list >>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > > -Chris > > -- > http://nondot.org/sabre/ > http://llvm.org/ > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From ralph at inputplus.co.uk Wed May 9 05:30:50 2007 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Wed, 09 May 2007 11:30:50 +0100 Subject: [LLVMdev] Problems with 'make check' In-Reply-To: <1178654659.18852.164.camel@bashful.x10sys.com> References: <024801c791a1$96ffd7e0$0200a8c0@AMD2500> <024d01c791a3$44976de0$0200a8c0@AMD2500> <027101c791a8$35c16af0$0200a8c0@AMD2500> <1178654659.18852.164.camel@bashful.x10sys.com> Message-ID: <20070509103050.528F414978E@blake.inputplus.co.uk> Hi Reid, > Please note that the path is (purposefully) not used to locate test > executables. Many of us have many LLVM environments and using the path > leads to confusion. What the makefile is looking for is the LLVMGCC > variable to be set. It wasn't so when substituted you get a null > string which leads to attempting to execute "-emit-llvm" (the first > argument after the null program name). You can resolve this by using > the --with-llvmgccdir option when configuring llvm. Might the makefile have an early target that does the shell if test x$LLVMGCC = x; then echo error message >&2; exit 1; fi in order to trap this common problem. Cheers, Ralph. From andrewl at lenharth.org Wed May 9 11:18:52 2007 From: andrewl at lenharth.org (Andrew Lenharth) Date: Wed, 9 May 2007 11:18:52 -0500 Subject: [LLVMdev] LLVM Developers Meeting - Dinner (Response needed) In-Reply-To: References: Message-ID: <85dfcd7f0705090918j6a3e4541ob7c1fc06cbfbf7f@mail.gmail.com> On 5/8/07, Tanya M. Lattner wrote: > So please email me by May 11th, if you plan to go to dinner. Count me in. Thanks Tanya. Andrew From greened at obbligato.org Wed May 9 11:45:46 2007 From: greened at obbligato.org (David Greene) Date: Wed, 09 May 2007 11:45:46 -0500 Subject: [LLVMdev] EquivalenceClasses Message-ID: <4641FABA.4020407@obbligato.org> Can someone explain the terminology used in the Doxygen comments for EquivalenceClasses? Specifically, what is a "Leader" as opposed to other members of an equivalence class? Say, for example, I want to create a set of equivalence classes to specify subset relationships. Imagine B is a subset of A, C is a subset of B, E is a subset of D and D has no relation to any other set. I'd like to group things into equivalence classes representing "immediate" subsets: Class 1: A, B Class 2: B, C Class 3: D, E Would A, B and D be the "Leaders" of the equivalence classes? Note that I don't want {A, B, C} as an equivalence class because it breaks the "immediate subset" relationship. With a relationship like equality, there is no problem because no member of the equivalence class has any different information about it than any other. But a relation like "subset" implies that members of the equivalence class are not all equal. Thanks for your help. -Dave From rspencer at reidspencer.com Wed May 9 14:47:04 2007 From: rspencer at reidspencer.com (Reid Spencer) Date: Wed, 09 May 2007 12:47:04 -0700 Subject: [LLVMdev] Compiling glibc on Linux In-Reply-To: References: <0C52DA88-E2EC-43D4-ADE8-C4A6B4C82522@uci.edu> <1178678020.18852.269.camel@bashful.x10sys.com> Message-ID: <1178740024.27417.8.camel@bashful.x10sys.com> Babak, I strongly suggest you drop trying to use llvmc. Instead, probably just compiling your library with llvm-gcc should be sufficient. The llvm-gcc tool has much of llc's functionality built in to it so you're going to get the same output. If that doesn't work for you, then please describe what you're trying to do in more detail and we'll tell you how it can be done. Coming at it from the "llvmc doesn't work" angle, doesn't help us solve your actual problem (because we don't know what it is). Thanks, Reid. On Wed, 2007-05-09 at 00:08 -0700, Babak Salamat wrote: > Thank you Chris. > > Actually, I have changed the stack organization in the "llc" source > codes for x86 target. Thus, I need libraries compiled with the new > stack organization. If I use llvm-gcc (and apparently also llvmc), > llc will not be invoked. I was hoping that llvmc would call llvm-gcc > to compile to bc file and then call llc to compile to native > assembly, but apparently this doesn't happen. > Do you know of any possible ways to involve llc in compilation of > libraries? > > --Babak > > On May 8, 2007, at 11:33 PM, Chris Lattner wrote: > > > On Tue, 8 May 2007, Babak Salamat wrote: > >> Yes, I have built and installed llvm-gcc and "llvm-gcc --print-prog- > >> name=cc1" return the correct path for cc1, so I assume its path is > >> set correctly in the config files, but I haven't installed config > >> files separately. Do I need to do that? Is there any documentation > >> about it? > > > > I'd strongly suggest just building with CC=llvm-gcc CXX=llvm-g++. > > > > llvmc is extremely experimental and has not seen wide use. > > > > -Chris > > > >> On May 8, 2007, at 7:33 PM, Reid Spencer wrote: > >> > >>> Babak, > >>> > >>> As its manual page (http://llvm.org/docs/CommandGuide/html/ > >>> llvmc.html) > >>> states, llvmc is an experimental tool: > >>> > >>> llvmc is considered an experimental LLVM tool because it has these > >>> deficiencies: > >>> > >>> Poor configuration support > >>> The support for configuring new languages, etc. is weak. > >>> There > >>> are many command line configurations that cannot be achieved > >>> with the current support. Furthermore the grammar is > >>> cumbersome > >>> for configuration files. Please see http://llvm.org/PR686 > >>> for > >>> further details. > >>> > >>> That said, you should be able to get it to work with llvm-gcc. > >>> > >>> Did you build llvm-gcc? Did you check the paths in the "c" config > >>> file? > >>> Did you install the config files? > >>> > >>> All of these things need to be done in order for the standard config > >>> file to work. > >>> > >>> Reid. > >>> > >>> On Tue, 2007-05-08 at 18:40 -0700, Babak Salamat wrote: > >>>> Hi, > >>>> > >>>> I am trying to compile glibc on Linux using llvm. I need to do this > >>>> for a research project. > >>>> The problem is that llvmc doesn't work, and I guess I have to set > >>>> CC=llvmc to get the glic compiled. For some reason llvmc complains > >>>> that it cannot find %llvmcc1%. I have this problem both on my > >>>> Mac and > >>>> my Linux system. Other tools that I have tested including llvm-gcc > >>>> work without any problem. > >>>> First, I appreciate it if you let me know what can cause this > >>>> problem > >>>> and second, tell me if you think I have any chance to compile glibc > >>>> using LLVM. > >>>> > >>>> Thank you, > >>>> Babak > >>>> > >>>> --------------------------------------------------------------- > >>>> Babak Salamat > >>>> PhD Student > >>>> Department of Computer Science > >>>> School of Information and Computer Sciences > >>>> University of California, Irvine > >>>> email: bsalamat at uci.edu > >>>> web: www.ics.uci.edu/~bsalamat > >>>> --------------------------------------------------------------- > >>>> > >>>> _______________________________________________ > >>>> LLVM Developers mailing list > >>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > >>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >>> > >>> _______________________________________________ > >>> LLVM Developers mailing list > >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >> > >> _______________________________________________ > >> LLVM Developers mailing list > >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >> > > > > -Chris > > > > -- > > http://nondot.org/sabre/ > > http://llvm.org/ > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From rspencer at reidspencer.com Wed May 9 14:50:07 2007 From: rspencer at reidspencer.com (Reid Spencer) Date: Wed, 09 May 2007 12:50:07 -0700 Subject: [LLVMdev] Problems with 'make check' In-Reply-To: <20070509103050.528F414978E@blake.inputplus.co.uk> References: <024801c791a1$96ffd7e0$0200a8c0@AMD2500> <024d01c791a3$44976de0$0200a8c0@AMD2500> <027101c791a8$35c16af0$0200a8c0@AMD2500> <1178654659.18852.164.camel@bashful.x10sys.com> <20070509103050.528F414978E@blake.inputplus.co.uk> Message-ID: <1178740207.27417.12.camel@bashful.x10sys.com> Ralph, On Wed, 2007-05-09 at 11:30 +0100, Ralph Corderoy wrote: > Hi Reid, > > > Please note that the path is (purposefully) not used to locate test > > executables. Many of us have many LLVM environments and using the path > > leads to confusion. What the makefile is looking for is the LLVMGCC > > variable to be set. It wasn't so when substituted you get a null > > string which leads to attempting to execute "-emit-llvm" (the first > > argument after the null program name). You can resolve this by using > > the --with-llvmgccdir option when configuring llvm. > > Might the makefile have an early target that does the shell > > if test x$LLVMGCC = x; then echo error message >&2; exit 1; fi > > in order to trap this common problem. When you configure llvm without llvm-gcc, you get a nice big warning message about it. I'm not sure anything more is needed. The approach you suggested will print out on every build, which is not so desirable. What could be done is add this to the "make check" target so that if LLVMGCC is not set, you get a big warning. However, I think the correct thing is to avoid any attempt at running the C/C++/Ada/ObjC tests if llvm-gcc is not present. This can be done simply by editing the dg.exp files in each of those directories. Reid. > > Cheers, > > > Ralph. > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From bsalamat at uci.edu Wed May 9 15:38:58 2007 From: bsalamat at uci.edu (Babak Salamat) Date: Wed, 9 May 2007 13:38:58 -0700 Subject: [LLVMdev] Compiling glibc on Linux In-Reply-To: <1178740024.27417.8.camel@bashful.x10sys.com> References: <0C52DA88-E2EC-43D4-ADE8-C4A6B4C82522@uci.edu> <1178678020.18852.269.camel@bashful.x10sys.com> <1178740024.27417.8.camel@bashful.x10sys.com> Message-ID: I am convinced to use llvm-gcc. As I mentioned in my previous email, I have changed native code generation in llc to generate code with a different stack organization. In order to have working binaries, the libraries must be compiled with the new tool and have the same stack organization. Now that I cannot use llc, it seems that I have to modify llvm-gcc to have it generate code with the stack organization that I want. For X86 target I have particularly changed X86RegisterInfo::eliminateFrameIndex, X86RegisterInfo::emitPrologue and X86RegisterInfo::emitEpilogue in the llc source code. Can I find equivalent functions in the llvm-gcc source, so that I can implement the needed stack organization? Thank you, Babak On May 9, 2007, at 12:47 PM, Reid Spencer wrote: > Babak, > > I strongly suggest you drop trying to use llvmc. Instead, probably > just > compiling your library with llvm-gcc should be sufficient. The llvm- > gcc > tool has much of llc's functionality built in to it so you're going to > get the same output. If that doesn't work for you, then please > describe > what you're trying to do in more detail and we'll tell you how it > can be > done. Coming at it from the "llvmc doesn't work" angle, doesn't > help us > solve your actual problem (because we don't know what it is). > > Thanks, > > Reid. > > On Wed, 2007-05-09 at 00:08 -0700, Babak Salamat wrote: >> Thank you Chris. >> >> Actually, I have changed the stack organization in the "llc" source >> codes for x86 target. Thus, I need libraries compiled with the new >> stack organization. If I use llvm-gcc (and apparently also llvmc), >> llc will not be invoked. I was hoping that llvmc would call llvm-gcc >> to compile to bc file and then call llc to compile to native >> assembly, but apparently this doesn't happen. >> Do you know of any possible ways to involve llc in compilation of >> libraries? >> >> --Babak >> >> On May 8, 2007, at 11:33 PM, Chris Lattner wrote: >> >>> On Tue, 8 May 2007, Babak Salamat wrote: >>>> Yes, I have built and installed llvm-gcc and "llvm-gcc --print- >>>> prog- >>>> name=cc1" return the correct path for cc1, so I assume its path is >>>> set correctly in the config files, but I haven't installed config >>>> files separately. Do I need to do that? Is there any documentation >>>> about it? >>> >>> I'd strongly suggest just building with CC=llvm-gcc CXX=llvm-g++. >>> >>> llvmc is extremely experimental and has not seen wide use. >>> >>> -Chris >>> >>>> On May 8, 2007, at 7:33 PM, Reid Spencer wrote: >>>> >>>>> Babak, >>>>> >>>>> As its manual page (http://llvm.org/docs/CommandGuide/html/ >>>>> llvmc.html) >>>>> states, llvmc is an experimental tool: >>>>> >>>>> llvmc is considered an experimental LLVM tool because it has these >>>>> deficiencies: >>>>> >>>>> Poor configuration support >>>>> The support for configuring new languages, etc. is weak. >>>>> There >>>>> are many command line configurations that cannot be >>>>> achieved >>>>> with the current support. Furthermore the grammar is >>>>> cumbersome >>>>> for configuration files. Please see http://llvm.org/PR686 >>>>> for >>>>> further details. >>>>> >>>>> That said, you should be able to get it to work with llvm-gcc. >>>>> >>>>> Did you build llvm-gcc? Did you check the paths in the "c" config >>>>> file? >>>>> Did you install the config files? >>>>> >>>>> All of these things need to be done in order for the standard >>>>> config >>>>> file to work. >>>>> >>>>> Reid. >>>>> >>>>> On Tue, 2007-05-08 at 18:40 -0700, Babak Salamat wrote: >>>>>> Hi, >>>>>> >>>>>> I am trying to compile glibc on Linux using llvm. I need to do >>>>>> this >>>>>> for a research project. >>>>>> The problem is that llvmc doesn't work, and I guess I have to set >>>>>> CC=llvmc to get the glic compiled. For some reason llvmc >>>>>> complains >>>>>> that it cannot find %llvmcc1%. I have this problem both on my >>>>>> Mac and >>>>>> my Linux system. Other tools that I have tested including llvm- >>>>>> gcc >>>>>> work without any problem. >>>>>> First, I appreciate it if you let me know what can cause this >>>>>> problem >>>>>> and second, tell me if you think I have any chance to compile >>>>>> glibc >>>>>> using LLVM. >>>>>> >>>>>> Thank you, >>>>>> Babak >>>>>> >>>>>> --------------------------------------------------------------- >>>>>> Babak Salamat >>>>>> PhD Student >>>>>> Department of Computer Science >>>>>> School of Information and Computer Sciences >>>>>> University of California, Irvine >>>>>> email: bsalamat at uci.edu >>>>>> web: www.ics.uci.edu/~bsalamat >>>>>> --------------------------------------------------------------- >>>>>> >>>>>> _______________________________________________ >>>>>> LLVM Developers mailing list >>>>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>>>> >>>>> _______________________________________________ >>>>> LLVM Developers mailing list >>>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>>> >>>> _______________________________________________ >>>> LLVM Developers mailing list >>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>>> >>> >>> -Chris >>> >>> -- >>> http://nondot.org/sabre/ >>> http://llvm.org/ >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From isanbard at gmail.com Wed May 9 15:49:46 2007 From: isanbard at gmail.com (Bill) Date: Wed, 9 May 2007 13:49:46 -0700 Subject: [LLVMdev] Compiling glibc on Linux In-Reply-To: References: <0C52DA88-E2EC-43D4-ADE8-C4A6B4C82522@uci.edu> <1178678020.18852.269.camel@bashful.x10sys.com> <1178740024.27417.8.camel@bashful.x10sys.com> Message-ID: <16e5fdf90705091349r12bcd703ra3218731ecaf29ea@mail.gmail.com> On 5/9/07, Babak Salamat wrote: > I am convinced to use llvm-gcc. As I mentioned in my previous email, > I have changed native code generation in llc to generate code with a > different stack organization. In order to have working binaries, the > libraries must be compiled with the new tool and have the same stack > organization. Now that I cannot use llc, it seems that I have to > modify llvm-gcc to have it generate code with the stack organization > that I want. > > For X86 target I have particularly changed > X86RegisterInfo::eliminateFrameIndex, X86RegisterInfo::emitPrologue > and X86RegisterInfo::emitEpilogue in the llc source code. > > Can I find equivalent functions in the llvm-gcc source, so that I can > implement the needed stack organization? > Hi Babak, Perhaps I don't understand you situation exactly, however llvm-gcc uses the same libraries the llc uses. Loosely speaking, the "gcc" part of llvm-gcc generates LLVM bytecode and sent to the LLVM libraries. >From there, it performs the optimizations and outputs code, etc. All that llc does differently is it reads the bytecode directly. It then sends it through the optimizers, etc. Therefore, your changes to X86RegisterInfo is shared with all tools. -bw From rspencer at reidspencer.com Wed May 9 15:57:50 2007 From: rspencer at reidspencer.com (Reid Spencer) Date: Wed, 09 May 2007 13:57:50 -0700 Subject: [LLVMdev] Compiling glibc on Linux In-Reply-To: References: <0C52DA88-E2EC-43D4-ADE8-C4A6B4C82522@uci.edu> <1178678020.18852.269.camel@bashful.x10sys.com> <1178740024.27417.8.camel@bashful.x10sys.com> Message-ID: <1178744270.27417.23.camel@bashful.x10sys.com> On Wed, 2007-05-09 at 13:38 -0700, Babak Salamat wrote: > I am convinced to use llvm-gcc. As I mentioned in my previous email, > I have changed native code generation in llc to generate code with a > different stack organization. In order to have working binaries, the > libraries must be compiled with the new tool and have the same stack > organization. Now that I cannot use llc, it seems that I have to > modify llvm-gcc to have it generate code with the stack organization > that I want. I think you're missing the point. llvm-gcc and llc link with *exactly* the same set of libraries for code generation. If you've modified llc then llvm-gcc (after rebuild) will produce the same results. If you've built your own target then you need to ensure that llvm-gcc links that target in by modifying the llvm-gcc/gcc/Makefile.in file. > > For X86 target I have particularly changed > X86RegisterInfo::eliminateFrameIndex, X86RegisterInfo::emitPrologue > and X86RegisterInfo::emitEpilogue in the llc source code. To be clear, llc does not contain any of those functions. They are part of the X86 target in lib/Target/X86. This is the same X86 target that is linked into llvm-gcc when you build it. There should be zero difference between your llvm-gcc output and your llc output. > > Can I find equivalent functions in the llvm-gcc source, so that I can > implement the needed stack organization? Yes you can .. its the same source! > > Thank you, > Babak Hope this clears it up. Reid. > > > On May 9, 2007, at 12:47 PM, Reid Spencer wrote: > > > Babak, > > > > I strongly suggest you drop trying to use llvmc. Instead, probably > > just > > compiling your library with llvm-gcc should be sufficient. The llvm- > > gcc > > tool has much of llc's functionality built in to it so you're going to > > get the same output. If that doesn't work for you, then please > > describe > > what you're trying to do in more detail and we'll tell you how it > > can be > > done. Coming at it from the "llvmc doesn't work" angle, doesn't > > help us > > solve your actual problem (because we don't know what it is). > > > > Thanks, > > > > Reid. > > > > On Wed, 2007-05-09 at 00:08 -0700, Babak Salamat wrote: > >> Thank you Chris. > >> > >> Actually, I have changed the stack organization in the "llc" source > >> codes for x86 target. Thus, I need libraries compiled with the new > >> stack organization. If I use llvm-gcc (and apparently also llvmc), > >> llc will not be invoked. I was hoping that llvmc would call llvm-gcc > >> to compile to bc file and then call llc to compile to native > >> assembly, but apparently this doesn't happen. > >> Do you know of any possible ways to involve llc in compilation of > >> libraries? > >> > >> --Babak > >> > >> On May 8, 2007, at 11:33 PM, Chris Lattner wrote: > >> > >>> On Tue, 8 May 2007, Babak Salamat wrote: > >>>> Yes, I have built and installed llvm-gcc and "llvm-gcc --print- > >>>> prog- > >>>> name=cc1" return the correct path for cc1, so I assume its path is > >>>> set correctly in the config files, but I haven't installed config > >>>> files separately. Do I need to do that? Is there any documentation > >>>> about it? > >>> > >>> I'd strongly suggest just building with CC=llvm-gcc CXX=llvm-g++. > >>> > >>> llvmc is extremely experimental and has not seen wide use. > >>> > >>> -Chris > >>> > >>>> On May 8, 2007, at 7:33 PM, Reid Spencer wrote: > >>>> > >>>>> Babak, > >>>>> > >>>>> As its manual page (http://llvm.org/docs/CommandGuide/html/ > >>>>> llvmc.html) > >>>>> states, llvmc is an experimental tool: > >>>>> > >>>>> llvmc is considered an experimental LLVM tool because it has these > >>>>> deficiencies: > >>>>> > >>>>> Poor configuration support > >>>>> The support for configuring new languages, etc. is weak. > >>>>> There > >>>>> are many command line configurations that cannot be > >>>>> achieved > >>>>> with the current support. Furthermore the grammar is > >>>>> cumbersome > >>>>> for configuration files. Please see http://llvm.org/PR686 > >>>>> for > >>>>> further details. > >>>>> > >>>>> That said, you should be able to get it to work with llvm-gcc. > >>>>> > >>>>> Did you build llvm-gcc? Did you check the paths in the "c" config > >>>>> file? > >>>>> Did you install the config files? > >>>>> > >>>>> All of these things need to be done in order for the standard > >>>>> config > >>>>> file to work. > >>>>> > >>>>> Reid. > >>>>> > >>>>> On Tue, 2007-05-08 at 18:40 -0700, Babak Salamat wrote: > >>>>>> Hi, > >>>>>> > >>>>>> I am trying to compile glibc on Linux using llvm. I need to do > >>>>>> this > >>>>>> for a research project. > >>>>>> The problem is that llvmc doesn't work, and I guess I have to set > >>>>>> CC=llvmc to get the glic compiled. For some reason llvmc > >>>>>> complains > >>>>>> that it cannot find %llvmcc1%. I have this problem both on my > >>>>>> Mac and > >>>>>> my Linux system. Other tools that I have tested including llvm- > >>>>>> gcc > >>>>>> work without any problem. > >>>>>> First, I appreciate it if you let me know what can cause this > >>>>>> problem > >>>>>> and second, tell me if you think I have any chance to compile > >>>>>> glibc > >>>>>> using LLVM. > >>>>>> > >>>>>> Thank you, > >>>>>> Babak > >>>>>> > >>>>>> --------------------------------------------------------------- > >>>>>> Babak Salamat > >>>>>> PhD Student > >>>>>> Department of Computer Science > >>>>>> School of Information and Computer Sciences > >>>>>> University of California, Irvine > >>>>>> email: bsalamat at uci.edu > >>>>>> web: www.ics.uci.edu/~bsalamat > >>>>>> --------------------------------------------------------------- > >>>>>> > >>>>>> _______________________________________________ > >>>>>> LLVM Developers mailing list > >>>>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > >>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >>>>> > >>>>> _______________________________________________ > >>>>> LLVM Developers mailing list > >>>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > >>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >>>> > >>>> _______________________________________________ > >>>> LLVM Developers mailing list > >>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > >>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >>>> > >>> > >>> -Chris > >>> > >>> -- > >>> http://nondot.org/sabre/ > >>> http://llvm.org/ > >>> _______________________________________________ > >>> LLVM Developers mailing list > >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >> > >> _______________________________________________ > >> LLVM Developers mailing list > >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From bsalamat at uci.edu Wed May 9 17:05:06 2007 From: bsalamat at uci.edu (Babak Salamat) Date: Wed, 9 May 2007 15:05:06 -0700 Subject: [LLVMdev] Compiling glibc on Linux In-Reply-To: <1178744270.27417.23.camel@bashful.x10sys.com> References: <0C52DA88-E2EC-43D4-ADE8-C4A6B4C82522@uci.edu> <1178678020.18852.269.camel@bashful.x10sys.com> <1178740024.27417.8.camel@bashful.x10sys.com> <1178744270.27417.23.camel@bashful.x10sys.com> Message-ID: <0D0CD844-006B-4DE4-AB8A-557410AE809F@uci.edu> Reid and Bill, Thank you very much for your helpful comments. Your comments helped me find out what part of my work was wrong that my changes were not effective in llvm-gcc. Thank you again, Babak On May 9, 2007, at 1:57 PM, Reid Spencer wrote: > On Wed, 2007-05-09 at 13:38 -0700, Babak Salamat wrote: >> I am convinced to use llvm-gcc. As I mentioned in my previous email, >> I have changed native code generation in llc to generate code with a >> different stack organization. In order to have working binaries, the >> libraries must be compiled with the new tool and have the same stack >> organization. Now that I cannot use llc, it seems that I have to >> modify llvm-gcc to have it generate code with the stack organization >> that I want. > > I think you're missing the point. llvm-gcc and llc link with *exactly* > the same set of libraries for code generation. If you've modified llc > then llvm-gcc (after rebuild) will produce the same results. > > If you've built your own target then you need to ensure that llvm-gcc > links that target in by modifying the llvm-gcc/gcc/Makefile.in file. > >> >> For X86 target I have particularly changed >> X86RegisterInfo::eliminateFrameIndex, X86RegisterInfo::emitPrologue >> and X86RegisterInfo::emitEpilogue in the llc source code. > > To be clear, llc does not contain any of those functions. They are > part > of the X86 target in lib/Target/X86. This is the same X86 target > that is > linked into llvm-gcc when you build it. There should be zero > difference > between your llvm-gcc output and your llc output. > >> >> Can I find equivalent functions in the llvm-gcc source, so that I can >> implement the needed stack organization? > > Yes you can .. its the same source! > >> >> Thank you, >> Babak > > Hope this clears it up. > > Reid. > >> >> >> On May 9, 2007, at 12:47 PM, Reid Spencer wrote: >> >>> Babak, >>> >>> I strongly suggest you drop trying to use llvmc. Instead, probably >>> just >>> compiling your library with llvm-gcc should be sufficient. The llvm- >>> gcc >>> tool has much of llc's functionality built in to it so you're >>> going to >>> get the same output. If that doesn't work for you, then please >>> describe >>> what you're trying to do in more detail and we'll tell you how it >>> can be >>> done. Coming at it from the "llvmc doesn't work" angle, doesn't >>> help us >>> solve your actual problem (because we don't know what it is). >>> >>> Thanks, >>> >>> Reid. >>> >>> On Wed, 2007-05-09 at 00:08 -0700, Babak Salamat wrote: >>>> Thank you Chris. >>>> >>>> Actually, I have changed the stack organization in the "llc" source >>>> codes for x86 target. Thus, I need libraries compiled with the new >>>> stack organization. If I use llvm-gcc (and apparently also llvmc), >>>> llc will not be invoked. I was hoping that llvmc would call llvm- >>>> gcc >>>> to compile to bc file and then call llc to compile to native >>>> assembly, but apparently this doesn't happen. >>>> Do you know of any possible ways to involve llc in compilation of >>>> libraries? >>>> >>>> --Babak >>>> >>>> On May 8, 2007, at 11:33 PM, Chris Lattner wrote: >>>> >>>>> On Tue, 8 May 2007, Babak Salamat wrote: >>>>>> Yes, I have built and installed llvm-gcc and "llvm-gcc --print- >>>>>> prog- >>>>>> name=cc1" return the correct path for cc1, so I assume its >>>>>> path is >>>>>> set correctly in the config files, but I haven't installed config >>>>>> files separately. Do I need to do that? Is there any >>>>>> documentation >>>>>> about it? >>>>> >>>>> I'd strongly suggest just building with CC=llvm-gcc CXX=llvm-g++. >>>>> >>>>> llvmc is extremely experimental and has not seen wide use. >>>>> >>>>> -Chris >>>>> >>>>>> On May 8, 2007, at 7:33 PM, Reid Spencer wrote: >>>>>> >>>>>>> Babak, >>>>>>> >>>>>>> As its manual page (http://llvm.org/docs/CommandGuide/html/ >>>>>>> llvmc.html) >>>>>>> states, llvmc is an experimental tool: >>>>>>> >>>>>>> llvmc is considered an experimental LLVM tool because it has >>>>>>> these >>>>>>> deficiencies: >>>>>>> >>>>>>> Poor configuration support >>>>>>> The support for configuring new languages, etc. is weak. >>>>>>> There >>>>>>> are many command line configurations that cannot be >>>>>>> achieved >>>>>>> with the current support. Furthermore the grammar is >>>>>>> cumbersome >>>>>>> for configuration files. Please see http://llvm.org/ >>>>>>> PR686 >>>>>>> for >>>>>>> further details. >>>>>>> >>>>>>> That said, you should be able to get it to work with llvm-gcc. >>>>>>> >>>>>>> Did you build llvm-gcc? Did you check the paths in the "c" >>>>>>> config >>>>>>> file? >>>>>>> Did you install the config files? >>>>>>> >>>>>>> All of these things need to be done in order for the standard >>>>>>> config >>>>>>> file to work. >>>>>>> >>>>>>> Reid. >>>>>>> >>>>>>> On Tue, 2007-05-08 at 18:40 -0700, Babak Salamat wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> I am trying to compile glibc on Linux using llvm. I need to do >>>>>>>> this >>>>>>>> for a research project. >>>>>>>> The problem is that llvmc doesn't work, and I guess I have >>>>>>>> to set >>>>>>>> CC=llvmc to get the glic compiled. For some reason llvmc >>>>>>>> complains >>>>>>>> that it cannot find %llvmcc1%. I have this problem both on my >>>>>>>> Mac and >>>>>>>> my Linux system. Other tools that I have tested including llvm- >>>>>>>> gcc >>>>>>>> work without any problem. >>>>>>>> First, I appreciate it if you let me know what can cause this >>>>>>>> problem >>>>>>>> and second, tell me if you think I have any chance to compile >>>>>>>> glibc >>>>>>>> using LLVM. >>>>>>>> >>>>>>>> Thank you, >>>>>>>> Babak >>>>>>>> >>>>>>>> --------------------------------------------------------------- >>>>>>>> Babak Salamat >>>>>>>> PhD Student >>>>>>>> Department of Computer Science >>>>>>>> School of Information and Computer Sciences >>>>>>>> University of California, Irvine >>>>>>>> email: bsalamat at uci.edu >>>>>>>> web: www.ics.uci.edu/~bsalamat >>>>>>>> --------------------------------------------------------------- >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> LLVM Developers mailing list >>>>>>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>>>>>> >>>>>>> _______________________________________________ >>>>>>> LLVM Developers mailing list >>>>>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>>>>> >>>>>> _______________________________________________ >>>>>> LLVM Developers mailing list >>>>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>>>>> >>>>> >>>>> -Chris >>>>> >>>>> -- >>>>> http://nondot.org/sabre/ >>>>> http://llvm.org/ >>>>> _______________________________________________ >>>>> LLVM Developers mailing list >>>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>>> >>>> _______________________________________________ >>>> LLVM Developers mailing list >>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From evan.cheng at apple.com Wed May 9 17:19:39 2007 From: evan.cheng at apple.com (Evan Cheng) Date: Wed, 9 May 2007 15:19:39 -0700 Subject: [LLVMdev] Patch for LLVM 2.0 release branch Message-ID: <2DFF95C2-6050-4DC9-897A-4702F2FB3722@apple.com> This one needs to go into the 2.0 branch: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of- Mon-20070507/049464.html This is required to fix a bug I introduced that breaks 177.mesa, distray, and cfrac on ARM. Evan From avayvod at gmail.com Wed May 9 17:21:26 2007 From: avayvod at gmail.com (Anton Vayvod) Date: Thu, 10 May 2007 02:21:26 +0400 Subject: [LLVMdev] EquivalenceClasses In-Reply-To: <4641FABA.4020407@obbligato.org> References: <4641FABA.4020407@obbligato.org> Message-ID: <808926ef0705091521wce07813r3eff8c3fff0662ed@mail.gmail.com> On 5/9/07, David Greene wrote: > > Can someone explain the terminology used in the Doxygen > comments for EquivalenceClasses? Specifically, what is > a "Leader" as opposed to other members of an equivalence > class? As far as I understand, leader is the first element of the class within the std::set container where all element of all classes are stored altogether. Leader contains a pointer to the last element of the class. The idea is similar to storing multiple linked lists in an array or in a vector. Leader elements allow iterating through class elements only via EquivalenceClasses::member_begin, member_end methods. Except of that there is no difference between the leader and the rest members of an equivalence class here. These leaders doesn't relate to coset leaders or something, AFAIK. It's not a mathematical notion there. Say, for example, I want to create a set of equivalence > classes to specify subset relationships. Imagine B is > a subset of A, C is a subset of B, E is a subset of D > and D has no relation to any other set. I'd like to > group things into equivalence classes representing > "immediate" subsets: > > Class 1: A, B > Class 2: B, C > Class 3: D, E I don't understand how A and B, for example, are equivalent. B is a subset of A but not vice versa. Thus your relation is not symmetric. Would A, B and D be the "Leaders" of the equivalence classes? > Note that I don't want {A, B, C} as an equivalence class > because it breaks the "immediate subset" relationship. > > With a relationship like equality, there is no problem because > no member of the equivalence class has any different information > about it than any other. But a relation like "subset" implies > that members of the equivalence class are not all equal. Equivalence classes are defined via equivalence relation. Subset is not one so this data structure just won't work correctly. I think that your relation should be represented by another structure. E.g. undirected graph can be used to represent any binary relation (if you chose binary matrix representation I'd recommend using BitSetVector data structure found in include/llvm/ADT directory). FYI, in linear scan register allocator EquivalenceClasses object is used to divide register classes via "alias" relation. See ComputeRelatedRegClasses method in RegAllocLinearScan.cpp. Anton. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20070510/e6b9af86/attachment.html From isanbard at gmail.com Wed May 9 17:38:57 2007 From: isanbard at gmail.com (Bill Wendling) Date: Wed, 9 May 2007 15:38:57 -0700 Subject: [LLVMdev] Compiling glibc on Linux In-Reply-To: <0D0CD844-006B-4DE4-AB8A-557410AE809F@uci.edu> References: <0C52DA88-E2EC-43D4-ADE8-C4A6B4C82522@uci.edu> <1178678020.18852.269.camel@bashful.x10sys.com> <1178740024.27417.8.camel@bashful.x10sys.com> <1178744270.27417.23.camel@bashful.x10sys.com> <0D0CD844-006B-4DE4-AB8A-557410AE809F@uci.edu> Message-ID: <16e5fdf90705091538y1e8fb134vc6a27e367d795e2e@mail.gmail.com> On 5/9/07, Babak Salamat wrote: > Reid and Bill, > > Thank you very much for your helpful comments. > Your comments helped me find out what part of my work was wrong that > my changes were not effective in llvm-gcc. > Cool! You're welcome :-) -bw From greened at obbligato.org Wed May 9 18:50:16 2007 From: greened at obbligato.org (David A. Greene) Date: Wed, 09 May 2007 18:50:16 -0500 Subject: [LLVMdev] EquivalenceClasses In-Reply-To: <808926ef0705091521wce07813r3eff8c3fff0662ed@mail.gmail.com> References: <4641FABA.4020407@obbligato.org> <808926ef0705091521wce07813r3eff8c3fff0662ed@mail.gmail.com> Message-ID: <46425E38.7030100@obbligato.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Anton Vayvod wrote: > I don't understand how A and B, for example, are equivalent. B is a > subset of A but not vice versa. Thus your relation is not symmetric. Correct. > Equivalence classes are defined via equivalence relation. Subset is not > one so this data structure just won't work correctly. That's what I suspected. I am in fact using a different data structure but wanted to make sure my reasoning about EquivalenceClasses was correct. Good to know I've been reasoning at least somewhat correctly about this. :) -Dave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGQl44gQsI8xjTYs8RAoNdAJ4wLt/GrJW4s144smwo8SIIYChJ6ACeJNFp /4FYVm2OEJw/gXvUPnc0Rdo= =XHym -----END PGP SIGNATURE----- From jconner at apple.com Wed May 9 14:06:07 2007 From: jconner at apple.com (Josh Conner) Date: Wed, 09 May 2007 12:06:07 -0700 Subject: [LLVMdev] LLVM Developer's Conference Message-ID: <46421B9F.3020703@apple.com> I'm planning on attending the LLVM Developer's Meeting. Thanks! - Josh ~~~~~~ Josh Conner Apple, Inc. From cfr at adobe.com Wed May 9 19:10:41 2007 From: cfr at adobe.com (Chuck Rose III) Date: Wed, 9 May 2007 17:10:41 -0700 Subject: [LLVMdev] LLVM Developers Meeting - Dinner (Response needed) In-Reply-To: Message-ID: <680422C0AA225644931C2F6DD07200DD9B35D3@namail5.corp.adobe.com> Hi Tanya, I will be there. Thanks, Chuck. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Tanya M. Lattner Sent: Tuesday, May 08, 2007 9:07 PM To: LLVM Developers Mailing List Subject: [LLVMdev] LLVM Developers Meeting - Dinner (Response needed) LLVM Developer Meeting Attendees, I need to get a count of the people planning to stay after the meeting for dinner. If we have a large enough group, we may need to make special arrangements. Attendees will have to pay for their own dinner, but we can get reservations or possibly reserve a banquet room. So please email me by May 11th, if you plan to go to dinner. Thanks, Tanya Lattner _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From tonic at nondot.org Thu May 10 00:09:33 2007 From: tonic at nondot.org (Tanya M. Lattner) Date: Wed, 9 May 2007 22:09:33 -0700 (PDT) Subject: [LLVMdev] Patch for LLVM 2.0 release branch In-Reply-To: <2DFF95C2-6050-4DC9-897A-4702F2FB3722@apple.com> References: <2DFF95C2-6050-4DC9-897A-4702F2FB3722@apple.com> Message-ID: Done! Thanks Evan. -Tanya On Wed, 9 May 2007, Evan Cheng wrote: > This one needs to go into the 2.0 branch: > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of- > Mon-20070507/049464.html > > This is required to fix a bug I introduced that breaks 177.mesa, > distray, and cfrac on ARM. > > Evan > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From isanbard at gmail.com Thu May 10 03:03:48 2007 From: isanbard at gmail.com (Bill Wendling) Date: Thu, 10 May 2007 01:03:48 -0700 Subject: [LLVMdev] LLVM Developer's Conference In-Reply-To: <46421B9F.3020703@apple.com> References: <46421B9F.3020703@apple.com> Message-ID: <7F1E19BA-1CBE-45B6-935A-0D80CAA45034@gmail.com> Hi Josh, You've been added! FYI: LLVM Developer Meeting Attendees, I need to get a count of the people planning to stay after the meeting for dinner. If we have a large enough group, we may need to make special arrangements. Attendees will have to pay for their own dinner, but we can get reservations or possibly reserve a banquet room. So please email me by May 11th, if you plan to go to dinner. Thanks, Tanya Lattner tonic at nondot.org On May 9, 2007, at 12:06 PM, Josh Conner wrote: > I'm planning on attending the LLVM Developer's Meeting. Thanks! > > - Josh > ~~~~~~ > Josh Conner > Apple, Inc. > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From basile at starynkevitch.net Thu May 10 04:29:32 2007 From: basile at starynkevitch.net (Basile STARYNKEVITCH) Date: Thu, 10 May 2007 11:29:32 +0200 Subject: [LLVMdev] 2.0 Release Process In-Reply-To: References: Message-ID: <20070510092932.GA18181@ours.starynkevitch.net> Le Tue, May 08, 2007 at 10:17:41PM -0700, Tanya M. Lattner ?crivait/wrote: > > Here is the schedule: > > May 7th - Release branch created. Developers should begin reviewing > all documentation. > > May 14th - Tar balls and binaries are released for general testing. I'll > also need volunteers to create additional llvm-gcc binaries that I have > not provided. > > May 18th - All documentation changes should have been merged into the > release branch. > > May 21st - Release! > What about the migration to SubVersion? Is it related to release of LLVM2.0? How will the svn migration happen? When should it be preferable or possible to use the svn command (instead of cvs) to get the latest LLVM source code? Regards -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basilestarynkevitchnet mobile: +33 6 8501 2359 8, rue de la Fa?encerie, 92340 Bourg La Reine, France *** opinions {are only mines, sont seulement les miennes} *** From avayvod at gmail.com Thu May 10 07:41:37 2007 From: avayvod at gmail.com (Anton Vayvod) Date: Thu, 10 May 2007 16:41:37 +0400 Subject: [LLVMdev] 2.0 Release Process In-Reply-To: <20070510092932.GA18181@ours.starynkevitch.net> References: <20070510092932.GA18181@ours.starynkevitch.net> Message-ID: <808926ef0705100541h114aa1cayd5340ea608aaf1c3@mail.gmail.com> probably, you'll find the answer here: http://llvm.org/SVNMigration.html On 5/10/07, Basile STARYNKEVITCH wrote: > > Le Tue, May 08, 2007 at 10:17:41PM -0700, Tanya M. Lattner ?crivait/wrote: > > > > Here is the schedule: > > > > May 7th - Release branch created. Developers should begin reviewing > > all documentation. > > > > May 14th - Tar balls and binaries are released for general testing. I'll > > also need volunteers to create additional llvm-gcc binaries that I have > > not provided. > > > > May 18th - All documentation changes should have been merged into the > > release branch. > > > > May 21st - Release! > > > > > What about the migration to SubVersion? Is it related to release of > LLVM2.0? > > How will the svn migration happen? When should it be preferable or > possible > to use the svn command (instead of cvs) to get the latest LLVM source > code? > > Regards > -- > Basile STARYNKEVITCH http://starynkevitch.net/Basile/ > email: basilestarynkevitchnet mobile: +33 6 8501 2359 > 8, rue de la Fa?encerie, 92340 Bourg La Reine, France > *** opinions {are only mines, sont seulement les miennes} *** > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > -- To become old and wise you need to be young and stupid first -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20070510/c2013dee/attachment.html From asl at math.spbu.ru Thu May 10 08:35:24 2007 From: asl at math.spbu.ru (Anton Korobeynikov) Date: Thu, 10 May 2007 17:35:24 +0400 Subject: [LLVMdev] 2.0 Release Process In-Reply-To: <20070510092932.GA18181.SS1158SS@ours.starynkevitch.net> References: <20070510092932.GA18181.SS1158SS@ours.starynkevitch.net> Message-ID: <1178804124.13114.115.camel@asl.dorms.spbu.ru> Hello, Basile. > What about the migration to SubVersion? Is it related to release of LLVM2.0? No. It will be (possible) in the mid June. > How will the svn migration happen? http://llvm.org/SVNMigration.html > When should it be preferable or possible > to use the svn command (instead of cvs) to get the latest LLVM source code? Soon after migration :) -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University. From ebner at complang.tuwien.ac.at Thu May 10 10:07:49 2007 From: ebner at complang.tuwien.ac.at (Dietmar Ebner) Date: Thu, 10 May 2007 17:07:49 +0200 Subject: [LLVMdev] llvm-test / parallel runs Message-ID: <1178809669.28072.6.camel@cdbook2.complang.tuwien.ac.at> hello, is there a simple way to run multiple benchmarks in parallel without breaking the reporting scripts? currently there's an explicit -j1 in Makefile.programs - i guess with purpose. we're simulating our target architecture and parallel builds/runs on multicore machines would drastically decrease the required simulation time. cheers, - dietmar From sabre at nondot.org Thu May 10 11:48:00 2007 From: sabre at nondot.org (Chris Lattner) Date: Thu, 10 May 2007 09:48:00 -0700 (PDT) Subject: [LLVMdev] llvm-test / parallel runs In-Reply-To: <1178809669.28072.6.camel@cdbook2.complang.tuwien.ac.at> References: <1178809669.28072.6.camel@cdbook2.complang.tuwien.ac.at> Message-ID: On Thu, 10 May 2007, Dietmar Ebner wrote: > is there a simple way to run multiple benchmarks in parallel without > breaking the reporting scripts? currently there's an explicit -j1 in > Makefile.programs - i guess with purpose. That -j1 serializes multiple tests within a directory. I routinely test with -j4 and get a major speedup over -j1 when running multiple directories of tests. -Chris > we're simulating our target architecture and parallel builds/runs on > multicore machines would drastically decrease the required simulation > time. -Chris -- http://nondot.org/sabre/ http://llvm.org/ From evan.cheng at apple.com Thu May 10 15:26:38 2007 From: evan.cheng at apple.com (Evan Cheng) Date: Thu, 10 May 2007 13:26:38 -0700 Subject: [LLVMdev] LLVM Developers Meeting - Dinner (Response needed) In-Reply-To: References: Message-ID: <1B8C5E51-28D8-4C52-8DBF-17E4DC098D56@apple.com> I'll attend if fish is on the menu. :-) Evan On May 8, 2007, at 9:06 PM, Tanya M. Lattner wrote: > LLVM Developer Meeting Attendees, > > I need to get a count of the people planning to stay after the > meeting for > dinner. If we have a large enough group, we may need to make special > arrangements. > > Attendees will have to pay for their own dinner, but we can get > reservations or possibly reserve a banquet room. > > So please email me by May 11th, if you plan to go to dinner. > > Thanks, > Tanya Lattner > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From rspencer at reidspencer.com Thu May 10 17:36:12 2007 From: rspencer at reidspencer.com (Reid Spencer) Date: Thu, 10 May 2007 15:36:12 -0700 Subject: [LLVMdev] T-Shirts: Last Call Message-ID: <1178836572.1233.65.camel@bashful.x10sys.com> To: Everyone That Ordered A T-Shirt Or Wants One If you want a T-Shirt but haven't ordered yet, you have until the 4pm PST tomorrow (24 hours from now) to let me know or alter your existing order. The T-Shirt is described this way: 437 JERZEES 50/50 Spot Shield Polo 50/50 cotton/poly blend, 5.6 oz. Treated with Spot Shield, most water and oil based stains bead up and roll off. 2-button placket, pearl buttons, double-needle hem. Sizes for this shirt are S, M, L, XL, 2XL, XXL. The shirt will have an embroidered LLVM Logo on the front left breast (where pocket usually goes). The embroidered logo will be a maroon (deep red) color. You can order the shirt in one of the following colors (use the link to see the shirt in that color), but remember that the maroon logo might not look good in all these colors. Birch, Black, Gold, Jade, Kelly Green, Maize, Navy, Purple, Putty, Sports Grey, Royal Blue, White I have orders for the following people. The size ordered is as noted below. The default color is "sports grey" which will look good with the maroon logo. If you want grey and the size is correct, you needn't do anything. If not, please send your changes to me (off list) and I will try to accommodate your request. Vikram Adve L + XL Owen Anderson M Bob Archer Largest Ryan Brown M Bruno Cardoso L Mike Engler L Han Gao L Dan Gohman L + XL Dale Johannsen XL Anton Korobeynikov M Christopher Lamb M Chris Lattner M Tanya Lattner S Andrew Lenharth XL Nick Lewycky L Efrem Lipkin XL Schimmel Mark L x 2 Gabe McArthur L Paul McJones L Scott McMurray M Scott Michel L Devang Patel M Jeff Poznanovic L Chuck Rose XL Al Stone XL Mark Thomas L Sarah Thompson XL Bill Wendling XL By default, T-Shirts will be delivered to you on May 25th at the meeting. If you are not attending, please provide your shipping address to me. I already have shipping addresses for Anton and Bruno. Thanks, Reid. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20070510/9c00b63c/attachment.html From criswell at cs.uiuc.edu Thu May 10 21:58:23 2007 From: criswell at cs.uiuc.edu (John T. Criswell) Date: Thu, 10 May 2007 21:58:23 -0500 Subject: [LLVMdev] T-Shirts: Last Call In-Reply-To: <1178836572.1233.65.camel@bashful.x10sys.com> References: <1178836572.1233.65.camel@bashful.x10sys.com> Message-ID: <4643DBCF.5070803@cs.uiuc.edu> Reid Spencer wrote: I'll take a large shirt in black. -- John T. > To: Everyone That Ordered A T-Shirt Or Wants One > > If you want a T-Shirt but haven't ordered yet, you have until the 4pm > PST tomorrow (24 hours from now) to let me know or alter your existing > order. > > The T-Shirt is described this way: *437 JERZEES 50/50 Spot Shield > Polo* 50/50 cotton/poly blend, 5.6 oz. Treated with Spot Shield, most > water and oil based stains bead up and roll off. 2-button placket, > pearl buttons, double-needle hem. Sizes for this shirt are S, M, L, > XL, 2XL, XXL. The shirt will have an embroidered LLVM Logo on the > front left breast (where pocket usually goes). The embroidered logo > will be a maroon (deep red) color. You can order the shirt in one of > the following colors (use the link to see the shirt in that color), > but remember that the maroon logo might not look good in all these colors. > > Birch, > Black > , Gold > , Jade > , Kelly > Green > , > Maize > , Navy > , > Purple > , > Putty > , > Sports Grey, > > Royal Blue > , > White > > I have orders for the following people. The size ordered is as noted > below. The default color is "sports grey" which will look good with > the maroon logo. If you want grey and the size is correct, you > needn't do anything. If not, please send your changes to me (off list) > and I will try to accommodate your request. > > Vikram Adve L + XL > Owen Anderson M > Bob Archer Largest > Ryan Brown M > Bruno Cardoso L > Mike Engler L > Han Gao L > Dan Gohman L + XL > Dale Johannsen XL > Anton Korobeynikov M > Christopher Lamb M > Chris Lattner M > Tanya Lattner S > Andrew Lenharth XL > Nick Lewycky L > Efrem Lipkin XL > Schimmel Mark L x 2 > Gabe McArthur L > Paul McJones L > Scott McMurray M > Scott Michel L > Devang Patel M > Jeff Poznanovic L > Chuck Rose XL > Al Stone XL > Mark Thomas L > Sarah Thompson XL > Bill Wendling XL > > > By default, T-Shirts will be delivered to you on May 25th at the > meeting. If you are not attending, please provide your shipping > address to me. I already have shipping addresses for Anton and Bruno. > > Thanks, > > Reid. > ------------------------------------------------------------------------ > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From feradz at gmail.com Fri May 11 11:18:37 2007 From: feradz at gmail.com (Ferad Zyulkyarov) Date: Fri, 11 May 2007 18:18:37 +0200 Subject: [LLVMdev] Instruction::getNext and Instruction::getPrev are private Message-ID: Hi, I switched to the upcoming version 2.0 branch and porting my code from 1.9. Thanks there is not a lot to do. I found that Instruction::getNext and Instruction::getPrev are private. Is this intentional? If yes, what would you recommend instead using them? Thanks, Ferad From gabor at mac.com Fri May 11 11:37:33 2007 From: gabor at mac.com (Gabor Greif) Date: Fri, 11 May 2007 18:37:33 +0200 Subject: [LLVMdev] Instruction::getNext and Instruction::getPrev are private Message-ID: <4DDFE805-6D48-46A9-9896-460F0736FAE6@mac.com> Hi Ferad! the change has been made with You have to use iterators now and "operator ++" etc. Hope this helps, cheers, Gabor From raju.subbian at windriver.com Fri May 11 12:01:35 2007 From: raju.subbian at windriver.com (Subbian, Raju) Date: Fri, 11 May 2007 10:01:35 -0700 Subject: [LLVMdev] T-Shirts: Last Call In-Reply-To: <1178836572.1233.65.camel@bashful.x10sys.com> References: <1178836572.1233.65.camel@bashful.x10sys.com> Message-ID: <7ED098B05D69FE41B380586BF1474DBA350D78@ala-mail08.corp.ad.wrs.com> Hi, I would like a large shirt in black. Thanks, Raju ________________________________ From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Reid Spencer Sent: Thursday, May 10, 2007 3:36 PM To: llvmdev Subject: [LLVMdev] T-Shirts: Last Call To: Everyone That Ordered A T-Shirt Or Wants One If you want a T-Shirt but haven't ordered yet, you have until the 4pm PST tomorrow (24 hours from now) to let me know or alter your existing order. The T-Shirt is described this way: 437 JERZEES 50/50 Spot Shield Polo 50/50 cotton/poly blend, 5.6 oz. Treated with Spot Shield, most water and oil based stains bead up and roll off. 2-button placket, pearl buttons, double-needle hem. Sizes for this shirt are S, M, L, XL, 2XL, XXL. The shirt will have an embroidered LLVM Logo on the front left breast (where pocket usually goes). The embroidered logo will be a maroon (deep red) color. You can order the shirt in one of the following colors (use the link to see the shirt in that color), but remember that the maroon logo might not look good in all these colors. Birch, Black , Gold , Jade , Kelly Green , Maize , Navy , Purple , Putty , Sports Grey, Royal Blue , White I have orders for the following people. The size ordered is as noted below. The default color is "sports grey" which will look good with the maroon logo. If you want grey and the size is correct, you needn't do anything. If not, please send your changes to me (off list) and I will try to accommodate your request. Vikram Adve L + XL Owen Anderson M Bob Archer Largest Ryan Brown M Bruno Cardoso L Mike Engler L Han Gao L Dan Gohman L + XL Dale Johannsen XL Anton Korobeynikov M Christopher Lamb M Chris Lattner M Tanya Lattner S Andrew Lenharth XL Nick Lewycky L Efrem Lipkin XL Schimmel Mark L x 2 Gabe McArthur L Paul McJones L Scott McMurray M Scott Michel L Devang Patel M Jeff Poznanovic L Chuck Rose XL Al Stone XL Mark Thomas L Sarah Thompson XL Bill Wendling XL By default, T-Shirts will be delivered to you on May 25th at the meeting. If you are not attending, please provide your shipping address to me. I already have shipping addresses for Anton and Bruno. Thanks, Reid. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20070511/ee0e0d10/attachment.html From feradz at gmail.com Fri May 11 12:39:44 2007 From: feradz at gmail.com (Ferad Zyulkyarov) Date: Fri, 11 May 2007 19:39:44 +0200 Subject: [LLVMdev] Instruction::getNext and Instruction::getPrev are private In-Reply-To: <1178901817.13114.126.camel@asl.dorms.spbu.ru> References: <1178901817.13114.126.camel@asl.dorms.spbu.ru> Message-ID: Thanks Antont and Gabor.. I will use the iterator instead.. On 5/11/07, Anton Korobeynikov wrote: > Hello, Ferad. > > > I switched to the upcoming version 2.0 branch and porting my code from > > 1.9. Thanks there is not a lot to do. I found that > > Instruction::getNext and Instruction::getPrev are private. Is this > > intentional? > Yes, incorrect usage of them caused hard-tracking bugs (e.g. calling > getNext() on terminator returns you the last "dummy" instruction in the > list, and so on). > > > If yes, what would you recommend instead using them? > Iterators? > > -- > With best regards, Anton Korobeynikov. > > Faculty of Mathematics & Mechanics, Saint Petersburg State University. > > > -- Ferad Zyulkyarov Barcelona Supercomputing Center From lefever at crhc.uiuc.edu Fri May 11 14:00:17 2007 From: lefever at crhc.uiuc.edu (Ryan M. Lefever) Date: Fri, 11 May 2007 14:00:17 -0500 Subject: [LLVMdev] identifing mallocs with constant sizes Message-ID: <4644BD41.2060508@crhc.uiuc.edu> I am writing some code to identify malloc instructions with constant request sizes and to determine the request size if it is constant. I have two questions. 1) If a malloc is for an array allocation and the array size is a ConstantExpr, how can I obtain the value of the ConstantExpr? 2) I am using the following logic to determine if the malloc is for a constant request size and to determine what is that size. Does the logic make sense? ============================================================ if (malloc is for non-array allocation){ -- the request size is constant and is equal to the size of allocated type } else{ // this is an array allocation if(array size is a Constant){ -- the request size is constant and equal to the size of the allocated type times the constant array size if(the array size is a ConstantInt){ -- the array size can be obtained using getLimitedValue() } else if(the array size is a ConstantExpr){ -- there should be some way to evaluate the constant expression??? } else if(the array size is a ConstantAggregateZero){ -- the malloc is for size 0 } else if(the array size is a ConstantFP){ -- I don't believe this case should happen but if it did, the array size could be obtained by calling getValue() } else if(the array size is a ConstantArray or ConstantPointerNull or ConstantStruct or ConstantVector or GlobalValue or UndefValue){ -- this should not happen! } } } in all other cases, the malloc is for a non-constant request size ============================================================= Regards, Ryan From criswell at cs.uiuc.edu Fri May 11 14:24:20 2007 From: criswell at cs.uiuc.edu (John Criswell) Date: Fri, 11 May 2007 14:24:20 -0500 Subject: [LLVMdev] identifing mallocs with constant sizes In-Reply-To: <4644BD41.2060508@crhc.uiuc.edu> References: <4644BD41.2060508@crhc.uiuc.edu> Message-ID: <4644C2E4.5020100@cs.uiuc.edu> Ryan M. Lefever wrote: > I am writing some code to identify malloc instructions with constant > request sizes and to determine the request size if it is constant. I > have two questions. > > 1) If a malloc is for an array allocation and the array size is a > ConstantExpr, how can I obtain the value of the ConstantExpr? > The only way I know of is to determine what type of constant expression it is and then evaluate it yourself. So, you'd have something like this: if (is a negation constantexpr) figure out the negated value of the operand if (is a cast constantexpr) figure out the result of the operand casted to the new type ... etc, etc. If anyone knows of a more efficient way, I'd be curious, too. I've had to write code that determines the value of a constant expression, too. > 2) I am using the following logic to determine if the malloc is for a > constant request size and to determine what is that size. Does the > logic make sense? > > ============================================================ > if (malloc is for non-array allocation){ > -- the request size is constant and is equal to the size of > allocated type > } > else{ > // this is an array allocation > > if(array size is a Constant){ > -- the request size is constant and equal to the size of the > allocated type times the constant array size > > if(the array size is a ConstantInt){ > -- the array size can be obtained using getLimitedValue() > } > else if(the array size is a ConstantExpr){ > -- there should be some way to evaluate the constant > expression??? > } > else if(the array size is a ConstantAggregateZero){ > -- the malloc is for size 0 > } > else if(the array size is a ConstantFP){ > -- I don't believe this case should happen but if it did, > the array size could be obtained by calling getValue() > } > else if(the array size is a ConstantArray or ConstantPointerNull > or ConstantStruct or ConstantVector or GlobalValue > or UndefValue){ > -- this should not happen! > } > } > } > > in all other cases, the malloc is for a non-constant request size > At a glance, this looks good, except that a ConstantInt is also a Constant, so I don't see the difference between the two cases. -- John T. > ============================================================= > > Regards, > Ryan > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From lefever at crhc.uiuc.edu Fri May 11 14:37:30 2007 From: lefever at crhc.uiuc.edu (Ryan M. Lefever) Date: Fri, 11 May 2007 14:37:30 -0500 Subject: [LLVMdev] identifing mallocs with constant sizes In-Reply-To: <4644C2E4.5020100@cs.uiuc.edu> References: <4644BD41.2060508@crhc.uiuc.edu> <4644C2E4.5020100@cs.uiuc.edu> Message-ID: <4644C5FA.3050703@crhc.uiuc.edu> John, Thanks for the reply! You said you'd written code to evaluate a constant expression, would it be possible for you to post that code? Ryan John Criswell wrote: > Ryan M. Lefever wrote: > >>I am writing some code to identify malloc instructions with constant >>request sizes and to determine the request size if it is constant. I >>have two questions. >> >>1) If a malloc is for an array allocation and the array size is a >>ConstantExpr, how can I obtain the value of the ConstantExpr? >> > > The only way I know of is to determine what type of constant expression > it is and then evaluate it yourself. So, you'd have something like this: > > if (is a negation constantexpr) > figure out the negated value of the operand > if (is a cast constantexpr) > figure out the result of the operand casted to the new type > ... > etc, etc. > > If anyone knows of a more efficient way, I'd be curious, too. I've had > to write code that determines the value of a constant expression, too. > >>2) I am using the following logic to determine if the malloc is for a >>constant request size and to determine what is that size. Does the >>logic make sense? >> >>============================================================ >>if (malloc is for non-array allocation){ >> -- the request size is constant and is equal to the size of >> allocated type >>} >>else{ >> // this is an array allocation >> >> if(array size is a Constant){ >> -- the request size is constant and equal to the size of the >> allocated type times the constant array size >> >> if(the array size is a ConstantInt){ >> -- the array size can be obtained using getLimitedValue() >> } >> else if(the array size is a ConstantExpr){ >> -- there should be some way to evaluate the constant >> expression??? >> } >> else if(the array size is a ConstantAggregateZero){ >> -- the malloc is for size 0 >> } >> else if(the array size is a ConstantFP){ >> -- I don't believe this case should happen but if it did, >> the array size could be obtained by calling getValue() >> } >> else if(the array size is a ConstantArray or ConstantPointerNull >> or ConstantStruct or ConstantVector or GlobalValue >> or UndefValue){ >> -- this should not happen! >> } >> } >>} >> >>in all other cases, the malloc is for a non-constant request size >> > > At a glance, this looks good, except that a ConstantInt is also a > Constant, so I don't see the difference between the two cases. > > -- John T. > > >>============================================================= >> >>Regards, >>Ryan >>_______________________________________________ >>LLVM Developers mailing list >>LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev -- Ryan M. Lefever [http://www.ews.uiuc.edu/~lefever] From greened at obbligato.org Fri May 11 17:24:22 2007 From: greened at obbligato.org (David Greene) Date: Fri, 11 May 2007 17:24:22 -0500 Subject: [LLVMdev] Live Intervals and Register Classes Message-ID: <4644ED16.8060700@obbligato.org> Given a live interval LI, what's the right way to get the register class of the interval? I'm assuming that all LiveRange entries in the LiveInterval are consistent in that if allocated to a register they would all go in the same register class. Fair assumption? If I take the first LiveRange LR from LI, look up its instruction/operand at "start" and then look at its TargetOperandInfo and send TOI::RegClass to MRegisterInfo:getRegClass, is that sufficient. It seems way overly complicated. After LiveIntervalAnalysis runs we have a set of LIs we can iterate over. What's the most efficient way to get the register classes for these intervals so I know which machine registers they can go into? -Dave From rafael.espindola at gmail.com Fri May 11 18:18:51 2007 From: rafael.espindola at gmail.com (=?UTF-8?Q?Rafael_Esp=C3=ADndola?=) Date: Sat, 12 May 2007 01:18:51 +0200 Subject: [LLVMdev] T-Shirts: Last Call In-Reply-To: <1178836572.1233.65.camel@bashful.x10sys.com> References: <1178836572.1233.65.camel@bashful.x10sys.com> Message-ID: <564d96fb0705111618v3132fbd9ja960b4f3970fd870@mail.gmail.com> White medium please. Yes, I am going :-) On 5/11/07, Reid Spencer wrote: > > To: Everyone That Ordered A T-Shirt Or Wants One > > If you want a T-Shirt but haven't ordered yet, you have until the 4pm PST > tomorrow (24 hours from now) to let me know or alter your existing order. > > The T-Shirt is described this way: 437 JERZEES 50/50 Spot Shield Polo 50/50 > cotton/poly blend, 5.6 oz. Treated with Spot Shield, most water and oil > based stains bead up and roll off. 2-button placket, pearl buttons, > double-needle hem. Sizes for this shirt are S, M, L, XL, 2XL, XXL. The > shirt will have an embroidered LLVM Logo on the front left breast (where > pocket usually goes). The embroidered logo will be a maroon (deep red) > color. You can order the shirt in one of the following colors (use the link > to see the shirt in that color), but remember that the maroon logo might not > look good in all these colors. > > Birch, Black, Gold, Jade, Kelly Green, Maize, Navy, Purple, Putty, Sports > Grey, Royal Blue, White > > I have orders for the following people. The size ordered is as noted below. > The default color is "sports grey" which will look good with the maroon > logo. If you want grey and the size is correct, you needn't do anything. If > not, please send your changes to me (off list) and I will try to accommodate > your request. > > > Vikram Adve L + XL > Owen Anderson M > Bob Archer Largest > Ryan Brown M > Bruno Cardoso L > Mike Engler L > Han Gao L > Dan Gohman L + XL > Dale Johannsen XL > Anton Korobeynikov M > Christopher Lamb M > Chris Lattner M > Tanya Lattner S > Andrew Lenharth XL > Nick Lewycky L > Efrem Lipkin XL > Schimmel Mark L x 2 > Gabe McArthur L > Paul McJones L > Scott McMurray M > Scott Michel L > Devang Patel M > Jeff Poznanovic L > Chuck Rose XL > Al Stone XL > Mark Thomas L > Sarah Thompson XL > Bill Wendling XL > By default, T-Shirts will be delivered to you on May 25th at the meeting. > If you are not attending, please provide your shipping address to me. I > already have shipping addresses for Anton and Bruno. > > Thanks, > > Reid. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > From greened at obbligato.org Fri May 11 18:14:19 2007 From: greened at obbligato.org (David Greene) Date: Fri, 11 May 2007 18:14:19 -0500 Subject: [LLVMdev] Live Intervals and Register Classes In-Reply-To: <4644ED16.8060700@obbligato.org> References: <4644ED16.8060700@obbligato.org> Message-ID: <4644F8CB.1080709@obbligato.org> David Greene wrote: > If I take the first LiveRange LR from LI, look up its > instruction/operand at "start" and then look at its > TargetOperandInfo and send TOI::RegClass to > MRegisterInfo:getRegClass, is that sufficient. > > It seems way overly complicated. Umm...yeah. That way be dragons. :-/ Fortunately, I found MachineFunction::getSSARegMap()->getRegClass(LI.reg) which works swimmingly. -Dave From sabre at nondot.org Fri May 11 18:52:27 2007 From: sabre at nondot.org (Chris Lattner) Date: Fri, 11 May 2007 16:52:27 -0700 (PDT) Subject: [LLVMdev] Live Intervals and Register Classes In-Reply-To: <4644F8CB.1080709@obbligato.org> References: <4644ED16.8060700@obbligato.org> <4644F8CB.1080709@obbligato.org> Message-ID: On Fri, 11 May 2007, David Greene wrote: > Umm...yeah. That way be dragons. :-/ > > Fortunately, I found > MachineFunction::getSSARegMap()->getRegClass(LI.reg) which > works swimmingly. Yep, that's exactly the right way to go for vregs. It won't work for physregs, primarily because they can be in multiple reg classes :) -Chris -- http://nondot.org/sabre/ http://llvm.org/ From napi at axiomsol.com Fri May 11 21:47:03 2007 From: napi at axiomsol.com (Mohd-Hanafiah Abdullah) Date: Sat, 12 May 2007 10:47:03 +0800 Subject: [LLVMdev] C back-end differences In-Reply-To: <8C785471-61D9-4FAA-8A03-6E708ED859D3@gmail.com> References: <1162701613.22790.15.camel@mobile> <1163738967.6023.6.camel@mobile.axiomsol.com> <1163752943.11597.16.camel@mobile.axiomsol.com> <455DD330.1000706@cs.uiuc.edu> <1163814113.6303.4.camel@mobile.axiomsol.com> <4561D985.3050402@cs.uiuc.edu> <1178640814.5737.3.camel@mobile> <16e5fdf90705081158oaca8a20n6f9faf3f218547fd@mail.gmail.com> <1178687158.6190.11.camel@mobile> <8C785471-61D9-4FAA-8A03-6E708ED859D3@gmail.com> Message-ID: <1178938023.6023.6.camel@mobile> On Tue, 2007-05-08 at 22:45 -0700, Bill Wendling wrote: > On May 8, 2007, at 10:05 PM, Mohd-Hanafiah Abdullah wrote: > > > On Tue, 2007-05-08 at 11:58 -0700, Bill wrote: > >> On 5/8/07, Mohd-Hanafiah Abdullah wrote: > >>> How does the C back-end of LLVM differ from the one in gcc2c > >>> developed > >>> by SUN several years ago? > >>> > >> Hi Napi, > >> > >> For one, it converts LLVM's bytecode to C instead of GCC's RTL. It's > >> also under a different license. > > > > Hi Bill: > > > > Would it be easier to convert from LLVM's bytecode to C as opposed to > > from RTL? What about the readability of the produced C code. I would > > think since RTL maintains a structure that is directly inherited from > > the high-level language structure it would be less difficult to > > turn it > > into some C code that is relatively more readable, as compared to > > synthesizing C code from the low-level bytecode. I stand corrected. > > > Hi Napi, > > Considering that LLVM already has a C backend, then it's easier to > generate it from the LLVM bytecode. :-) LLVM's intermediate > representation of the program (the bytecode) is also derived directly > from the high-level language. When it gets to the C backend part, it > simply has had transformations done on it. > > I don't believe that the C backend was made for readability. In fact, > because LLVM is in SSA form, it uses many temporary variables and > loses a lot of the information about what the original variable's > name was. > > The best way to get a feel for how it is is to write a program and > generate the C code for it with the LLVM backend. (See the llc tool > for information on this.) > > Though, this begs the question of why you want to use something which > converts it to C instead of just using one of the target backends to > generate native code. Hi Bill: I've been looking for a C++ to C translator for quite some time. The purpose is to support C++ for the compiler I developed targeting the JVM. But the compiler I wrote only supports ANSI C (1989). So the C++ to C translator is needed, and among the options are as follows: a) EDG (rather expensive, around USD 100K with source code) b) Comeau (around USD 25K for customization service and you don't get the source code) c) LLVM (tried, but the resulting C code is quite hairy, pardon the expression) d) gcc2c (trying now, don't know how useful yet) For more info on the said C to JVM compiler you can check out our website: http://www.axiomsol.com Cheers. Napi From me22.ca at gmail.com Fri May 11 22:15:42 2007 From: me22.ca at gmail.com (me22) Date: Fri, 11 May 2007 23:15:42 -0400 Subject: [LLVMdev] C back-end differences In-Reply-To: <1178938023.6023.6.camel@mobile> References: <1162701613.22790.15.camel@mobile> <455DD330.1000706@cs.uiuc.edu> <1163814113.6303.4.camel@mobile.axiomsol.com> <4561D985.3050402@cs.uiuc.edu> <1178640814.5737.3.camel@mobile> <16e5fdf90705081158oaca8a20n6f9faf3f218547fd@mail.gmail.com> <1178687158.6190.11.camel@mobile> <8C785471-61D9-4FAA-8A03-6E708ED859D3@gmail.com> <1178938023.6023.6.camel@mobile> Message-ID: On 11/05/07, Mohd-Hanafiah Abdullah wrote: > I've been looking for a C++ to C translator for quite some time. > The purpose is to support C++ for the compiler I developed targeting the > JVM. But the compiler I wrote only supports ANSI C (1989). So the C++ > to C translator is needed, and among the options are as follows: > [...] > c) LLVM (tried, but the resulting C code is quite hairy, pardon the > expression) > So you just want to feed the C code to your C-to-JVM compiler? I don't understand why "hairy" code would be a problem for that usage. As a different option, how about writing a JVM backend for LLVM? From napi at axiomsol.com Fri May 11 22:26:49 2007 From: napi at axiomsol.com (Mohd-Hanafiah Abdullah) Date: Sat, 12 May 2007 11:26:49 +0800 Subject: [LLVMdev] C back-end differences In-Reply-To: References: <1162701613.22790.15.camel@mobile> <455DD330.1000706@cs.uiuc.edu> <1163814113.6303.4.camel@mobile.axiomsol.com> <4561D985.3050402@cs.uiuc.edu> <1178640814.5737.3.camel@mobile> <16e5fdf90705081158oaca8a20n6f9faf3f218547fd@mail.gmail.com> <1178687158.6190.11.camel@mobile> <8C785471-61D9-4FAA-8A03-6E708ED859D3@gmail.com> <1178938023.6023.6.camel@mobile> Message-ID: <1178940409.6023.13.camel@mobile> On Fri, 2007-05-11 at 23:15 -0400, me22 wrote: > On 11/05/07, Mohd-Hanafiah Abdullah wrote: > > I've been looking for a C++ to C translator for quite some time. > > The purpose is to support C++ for the compiler I developed targeting the > > JVM. But the compiler I wrote only supports ANSI C (1989). So the C++ > > to C translator is needed, and among the options are as follows: > > [...] > > c) LLVM (tried, but the resulting C code is quite hairy, pardon the > > expression) > > > So you just want to feed the C code to your C-to-JVM compiler? I don't > understand why "hairy" code would be a problem for that usage. > > As a different option, how about writing a JVM backend for LLVM? This is definitely an option too. Another one would be to write a JVM backend for gcc. But, I think somebody tried many years ago and stopped halfway (it's egcs-jvm I think). Does LLVM use RTL as intermediate language like gcc does? Thanks. Napi From me22.ca at gmail.com Fri May 11 22:40:08 2007 From: me22.ca at gmail.com (me22) Date: Fri, 11 May 2007 23:40:08 -0400 Subject: [LLVMdev] C back-end differences In-Reply-To: <1178940409.6023.13.camel@mobile> References: <1162701613.22790.15.camel@mobile> <1163814113.6303.4.camel@mobile.axiomsol.com> <4561D985.3050402@cs.uiuc.edu> <1178640814.5737.3.camel@mobile> <16e5fdf90705081158oaca8a20n6f9faf3f218547fd@mail.gmail.com> <1178687158.6190.11.camel@mobile> <8C785471-61D9-4FAA-8A03-6E708ED859D3@gmail.com> <1178938023.6023.6.camel@mobile> <1178940409.6023.13.camel@mobile> Message-ID: On 11/05/07, Mohd-Hanafiah Abdullah wrote: > This is definitely an option too. Another one would be to write a JVM > backend for gcc. But, I think somebody tried many years ago and stopped > halfway (it's egcs-jvm I think). Does LLVM use RTL as intermediate > language like gcc does? > I'm not exactly sure how llvm-g++ works. I think it goes through the standard gcc sequence (gimple, rtl, and such) but then outputs LLVM (http://llvm.org/docs/LangRef.html), which is the intermediate representation used by the rest of the chain. To make an LLVM backend you would not need to deal with RTL and such at all. There's a name change in progress to make it clearer that what's now called LLVM is much more than just the LLVM language :) ~ Scott From sabre at nondot.org Sat May 12 01:38:34 2007 From: sabre at nondot.org (Chris Lattner) Date: Fri, 11 May 2007 23:38:34 -0700 (PDT) Subject: [LLVMdev] C back-end differences In-Reply-To: References: <1162701613.22790.15.camel@mobile> <1163814113.6303.4.camel@mobile.axiomsol.com> <4561D985.3050402@cs.uiuc.edu> <1178640814.5737.3.camel@mobile> <16e5fdf90705081158oaca8a20n6f9faf3f218547fd@mail.gmail.com> <1178687158.6190.11.camel@mobile> <8C785471-61D9-4FAA-8A03-6E708ED859D3@gmail.com> <1178938023.6023.6.camel@mobile> <1178940409.6023.13.camel@mobile> Message-ID: On Fri, 11 May 2007, me22 wrote: > I'm not exactly sure how llvm-g++ works. I think it goes through the > standard gcc sequence (gimple, rtl, and such) but then outputs LLVM > (http://llvm.org/docs/LangRef.html), which is the intermediate > representation used by the rest of the chain. To make an LLVM backend > you would not need to deal with RTL and such at all. llvm-g++ converts from trees to high-gimple to LLVM. RTL is not involved. LLVM also does have an MSIL backend, if you are interested in a JVM backend, it may be a starting point. -Chris -- http://nondot.org/sabre/ http://llvm.org/ From avayvod at gmail.com Sat May 12 01:51:01 2007 From: avayvod at gmail.com (Anton Vayvod) Date: Sat, 12 May 2007 10:51:01 +0400 Subject: [LLVMdev] Live Intervals and Register Classes In-Reply-To: References: <4644ED16.8060700@obbligato.org> <4644F8CB.1080709@obbligato.org> Message-ID: <808926ef0705112351i2a68b961kd6e613daaae2b96@mail.gmail.com> David, Probably, you'll find a lot of useful information here along with the answer to your question (that you've found already): http://llvm.org/docs/CodeGenerator.html#regalloc Anton. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20070512/30112ddc/attachment.html From basile at starynkevitch.net Sat May 12 16:45:55 2007 From: basile at starynkevitch.net (Basile STARYNKEVITCH) Date: Sat, 12 May 2007 23:45:55 +0200 Subject: [LLVMdev] reading a module from a memory string (BitCode) Message-ID: <20070512214554.GA13706@ours.starynkevitch.net> Hello, with the latest LLVM (almost 2.0 CVS) what is the right way to read a module from a byte array fetched from a database? I thought that I could subclass llbm::module to add my own fields (typically, a MySQL id number) and then parse it as bitcode, but I am stuck, since apparently the only way to parse bitcode is to use a BitcodeReader then calling materializeModule gives a fresh llvm Module (not my subclass) As a general question, are Llvm classes supposed to be usually subclassed to add application data (like my modtime and id), or not... Does any one have some example of reading Bitcode encoded modules? Can I assume that such modules are not tied to a particular (LLVM target) architecture, in other words can I store into my database modules build on AMD64 and reload them on x86 (32 bits)? Regards. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basilestarynkevitchnet mobile: +33 6 8501 2359 8, rue de la Fa?encerie, 92340 Bourg La Reine, France *** opinions {are only mines, sont seulement les miennes} *** From rspencer at reidspencer.com Sat May 12 17:40:10 2007 From: rspencer at reidspencer.com (Reid Spencer) Date: Sat, 12 May 2007 22:40:10 +0000 Subject: [LLVMdev] reading a module from a memory string (BitCode) In-Reply-To: <20070512214554.GA13706@ours.starynkevitch.net> References: <20070512214554.GA13706@ours.starynkevitch.net> Message-ID: <1179009610.1233.141.camel@bashful.x10sys.com> Hi Basile, On Sat, 2007-05-12 at 23:45 +0200, Basile STARYNKEVITCH wrote: > Hello, > > with the latest LLVM (almost 2.0 CVS) what is the right way to read a module > from a byte array fetched from a database? Add your own blocks > I thought that I could subclass llbm::module to add my own fields > (typically, a MySQL id number) and then parse it as bitcode, but I am stuck, > since apparently the only way to parse bitcode is to use a BitcodeReader > then calling materializeModule gives a fresh llvm Module (not my subclass) LLVM only knows how to read LLVM stuff. If you want to "add" stuff, you need to do it in a separate block. The bitstream format is flexible enough to support reading a new file format that is LLVM+your_stuff. > > As a general question, are Llvm classes supposed to be usually subclassed to > add application data (like my modtime and id), or not... No, not generally. What is it that you're trying to do? Sounds like maybe you're trying to do "front end" type things. The HLVM front end libraries will assist with many of these kinds of things (associating source line, language identifier, managled identifier, etc. with corresponding LLVM nodes). The general approach is to keep references back to the LLVM objects from another block. None of this exists yet in HLVM, but it will this summer. > > Does any one have some example of reading Bitcode encoded modules? Bitcode is only a few weeks old, so I doubt it :) > Can I assume that such modules are not tied to a particular (LLVM target) > architecture, in other words can I store into my database modules build on > AMD64 and reload them on x86 (32 bits)? Depends on whether you mean "bitcode file format" or "LLVM module". A module can definitely be tied to a specific target. It completely depends on what the front end language compiler generates. From a bitcode file format perspective, the files should be portable as they are treated as a stream of bits without concern for endianness, etc. Your example will work from a file format perspective (you'll get the same bits out as you got in and they'll have the same interpretation on the x86 as on the AMD64). But, that doesn't mean it will execute correctly. If the module has no inline assembly or any other target specific features (like differences in alignment) then it could work. Your front end will determine how well this works. If the front end is llvm-gcc then the answer is "won't work, in general, but might work on specific test cases". Reid. > > Regards. From sabre at nondot.org Sat May 12 18:42:49 2007 From: sabre at nondot.org (Chris Lattner) Date: Sat, 12 May 2007 16:42:49 -0700 (PDT) Subject: [LLVMdev] reading a module from a memory string (BitCode) In-Reply-To: <20070512214554.GA13706@ours.starynkevitch.net> References: <20070512214554.GA13706@ours.starynkevitch.net> Message-ID: On Sat, 12 May 2007, Basile STARYNKEVITCH wrote: > with the latest LLVM (almost 2.0 CVS) what is the right way to read a module > from a byte array fetched from a database? The bitcode reader will read from any MemoryBuffer object. There are a variety of static methods on MemoryBuffer to create them from files, stdio, and memory. If your buffer is in memory, just create a memorybuffer and pass in the range of bytes already in memory. Once the appropriate MemoryBuffer is created, you load it like any other bitcode stream. > I thought that I could subclass llbm::module to add my own fields > (typically, a MySQL id number) and then parse it as bitcode, but I am stuck, > since apparently the only way to parse bitcode is to use a BitcodeReader > then calling materializeModule gives a fresh llvm Module (not my subclass) Right, don't do that :). There are three easy ways to do this sort of thing: 1) add intrinsics to capture the information you want, 2) encode the information as global variable initializers (as we do with debug info) 3) store it out-of-band, as reid suggests. > As a general question, are Llvm classes supposed to be usually subclassed to > add application data (like my modtime and id), or not... no. > Does any one have some example of reading Bitcode encoded modules? Can I > assume that such modules are not tied to a particular (LLVM target) > architecture, in other words can I store into my database modules build on > AMD64 and reload them on x86 (32 bits)? LLVM IR is, in general, not portable if it comes from a non-portable source language like C. -Chris -- http://nondot.org/sabre/ http://llvm.org/ From basile at starynkevitch.net Sun May 13 15:20:48 2007 From: basile at starynkevitch.net (Basile STARYNKEVITCH) Date: Sun, 13 May 2007 22:20:48 +0200 Subject: [LLVMdev] reading a module from a memory string (BitCode) In-Reply-To: References: <20070512214554.GA13706@ours.starynkevitch.net> Message-ID: <20070513202048.GA9033@ours.starynkevitch.net> Le Sat, May 12, 2007 at 04:42:49PM -0700, Chris Lattner ?crivait/wrote: > On Sat, 12 May 2007, Basile STARYNKEVITCH wrote: > > with the latest LLVM (almost 2.0 CVS) what is the right way to read a module > > from a byte array fetched from a database? > > The bitcode reader will read from any MemoryBuffer object. There are a > variety of static methods on MemoryBuffer to create them from files, > stdio, and memory. If your buffer is in memory, just create a > memorybuffer and pass in the range of bytes already in memory. Once the > appropriate MemoryBuffer is created, you load it like any other bitcode > stream. Apparently BitcodeReader.h is only in lib/Bitcode/Reader/ but not in include, so a make install does not install it. Is it supposed to be accessible from applications? How exactly? I feel that some install rule is missing; after a sudo make install, grep -rn BitcodeReader /usr/local/include/llvm/ don't find any occurrence! Is this a bug or a misunderstanding of mine? Can I assume the bytecode interface is obsolete and to be replaced by bitcode? BTW, my hoobby project is an hypertextual programming language experiment with only a Web interface (no source files). So I want to store every procuced llbm Module in a MySQL database. Regards -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basilestarynkevitchnet mobile: +33 6 8501 2359 8, rue de la Fa?encerie, 92340 Bourg La Reine, France *** opinions {are only mines, sont seulement les miennes} *** From sabre at nondot.org Sun May 13 16:59:07 2007 From: sabre at nondot.org (Chris Lattner) Date: Sun, 13 May 2007 14:59:07 -0700 (PDT) Subject: [LLVMdev] reading a module from a memory string (BitCode) In-Reply-To: <20070513202048.GA9033@ours.starynkevitch.net> References: <20070512214554.GA13706@ours.starynkevitch.net> <20070513202048.GA9033@ours.starynkevitch.net> Message-ID: On Sun, 13 May 2007, Basile STARYNKEVITCH wrote: > Apparently BitcodeReader.h is only in lib/Bitcode/Reader/ but not in > include, so a make install does not install it. I'm not sure what you mean... the header is in include/llvm/Bitcode. > Is it supposed to be accessible from applications? How exactly? I feel that > some install rule is missing; after a sudo make install, > grep -rn BitcodeReader /usr/local/include/llvm/ > don't find any occurrence! Is this a bug or a misunderstanding of mine? I think there is something strange going on :) Try doing a full update from cvs. > Can I assume the bytecode interface is obsolete and to be replaced by > bitcode? Bytecode is completely gone now. > BTW, my hoobby project is an hypertextual programming language experiment > with only a Web interface (no source files). So I want to store every > procuced llbm Module in a MySQL database. That shouldn't be a problem! -Chris -- http://nondot.org/sabre/ http://llvm.org/ From basile at starynkevitch.net Mon May 14 01:43:32 2007 From: basile at starynkevitch.net (Basile STARYNKEVITCH) Date: Mon, 14 May 2007 08:43:32 +0200 Subject: [LLVMdev] reading a module from a memory string (BitCode) Message-ID: <20070514064332.GA21516@ours.starynkevitch.net> >> Apparently BitcodeReader.h is only in lib/Bitcode/Reader/ but not in >> include, so a make install does not install it. >I'm not sure what you mean... the header is in include/llvm/Bitcode. >> Is it supposed to be accessible from applications? How exactly? I feel that >> some install rule is missing; after a sudo make install, >> grep -rn BitcodeReader /usr/local/include/llvm/ >> don't find any occurrence! Is this a bug or a misunderstanding of mine? >I think there is something strange going on :) Try doing a full update > I just cleaned entirely my local CVS copy, and checked it out again. Then I mkdir _Obj64 (on Linux/Debian/Sid/AMD64 system, with g++-4.1) and did cd /usr/src/Lang/llvm/_Obj64 # prefix is the default /usr/local/ "../configure" '--enable-static' '--enable-targets=host-only' '--enable-doxygen' '--with-gnu-ld' make sudo make install But still getting find /usr/local/include/llvm -name 'Bit*eader*' /usr/local/include/llvm/Bitcode/BitstreamReader.h and grep -rni BitcodeReader /usr/local/include/llvm remains desperately silent. Obviously, I made a mistake which I cannot find yet. Any help please? Regards. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basilestarynkevitchnet mobile: +33 6 8501 2359 8, rue de la Fa?encerie, 92340 Bourg La Reine, France *** opinions {are only mines, sont seulement les miennes} *** From duraid at octopus.com.au Mon May 14 01:44:41 2007 From: duraid at octopus.com.au (Duraid Madina) Date: Mon, 14 May 2007 15:44:41 +0900 Subject: [LLVMdev] FORTRAN compiler status? Message-ID: <46480559.90608@octopus.com.au> Dear LLVMers, Does anyone know what the latest is w.r.t a FORTRAN front-end for LLVM? Is anyone expecting to have typical f90/f95 programs compiling to LLVM this year, or next? (I'm aware of the "NAG hack" and various other f2c-type approaches, but they give me a strange feeling in my tummy.) Duraid From sabre at nondot.org Mon May 14 02:33:30 2007 From: sabre at nondot.org (Chris Lattner) Date: Mon, 14 May 2007 00:33:30 -0700 (PDT) Subject: [LLVMdev] reading a module from a memory string (BitCode) In-Reply-To: <20070514064332.GA21516@ours.starynkevitch.net> References: <20070514064332.GA21516@ours.starynkevitch.net> Message-ID: On Mon, 14 May 2007, Basile STARYNKEVITCH wrote: > But still getting > find /usr/local/include/llvm -name 'Bit*eader*' > /usr/local/include/llvm/Bitcode/BitstreamReader.h > > and grep -rni BitcodeReader /usr/local/include/llvm > remains desperately silent. > > Obviously, I made a mistake which I cannot find yet. Any help please? You want: include/llvm/Bitcode/ReaderWriter.h -Chris -- http://nondot.org/sabre/ http://llvm.org/ From rspencer at reidspencer.com Mon May 14 01:57:03 2007 From: rspencer at reidspencer.com (Reid Spencer) Date: Mon, 14 May 2007 06:57:03 +0000 Subject: [LLVMdev] reading a module from a memory string (BitCode) In-Reply-To: <20070514064332.GA21516@ours.starynkevitch.net> References: <20070514064332.GA21516@ours.starynkevitch.net> Message-ID: <1179125823.1233.187.camel@bashful.x10sys.com> Hi Basile, On Mon, 2007-05-14 at 08:43 +0200, Basile STARYNKEVITCH wrote: > >> Apparently BitcodeReader.h is only in lib/Bitcode/Reader/ but not in > >> include, so a make install does not install it. > > >I'm not sure what you mean... the header is in include/llvm/Bitcode. > > >> Is it supposed to be accessible from applications? How exactly? I feel that > >> some install rule is missing; after a sudo make install, > >> grep -rn BitcodeReader /usr/local/include/llvm/ > >> don't find any occurrence! Is this a bug or a misunderstanding of mine? > > >I think there is something strange going on :) Try doing a full update > > > > I just cleaned entirely my local CVS copy, and checked it out again. > > Then I mkdir _Obj64 (on Linux/Debian/Sid/AMD64 system, with g++-4.1) and did > cd /usr/src/Lang/llvm/_Obj64 > # prefix is the default /usr/local/ > "../configure" '--enable-static' '--enable-targets=host-only' '--enable-doxygen' '--with-gnu-ld' > make > sudo make install > > But still getting > find /usr/local/include/llvm -name 'Bit*eader*' > /usr/local/include/llvm/Bitcode/BitstreamReader.h > > and grep -rni BitcodeReader /usr/local/include/llvm > remains desperately silent. > > Obviously, I made a mistake which I cannot find yet. Any help please? That all looks correct to me. The BitcodeReader.h file is a private implementation header located in lib/Bitcode/Reader and it won't get installed. The BitstreamReader.h file is the public interface to (generic) bitstream reading. The ReaderWriter.h file should also be installed in your /usr/local/include/llvm/Bitcode directory. This is the public interface to reading and writing LLVM bitcode (LLVM specific bitstream files). If this is insufficient for you then you need to talk to Chris Lattner about making additional (private) interfaces in BitcodeReader.h available in ReaderWriter.h Reid. > > Regards. From clattner at apple.com Mon May 14 02:10:09 2007 From: clattner at apple.com (Chris Lattner) Date: Mon, 14 May 2007 00:10:09 -0700 Subject: [LLVMdev] llvm 2.0 release announcement [draft] Message-ID: <03B1371C-3773-41A0-B09A-E7AFE335CF16@apple.com> Hi Everyone, It is getting to be that time again. I've scoured llvm-commits and collected a list of some of the major features we've developed since the last status update (from Feb 21). Please take a look and send me (off list) additions, feedback, corrections, etc. As usual, if I missed something, it's probably because there is such a huge amount of stuff happening, please let me know! Finally, I'm planning to start hacking on the release notes (llvm/ docs/ReleaseNotes.html), but there is a lot of great stuff to be mentioned and doing so takes a lot of time. I would appreciate all help I can get with this. The first place to start is by merging the major contents of this announcement and the previous one into the release notes. If you maintain a target, or any other portion of the compiler, please ensure the release notes adequately reflect the state of your component. Thanks! -Chris ---- 8< -------- 8< ---- ... intro ... LLVM is being used for a broad variety of academic research projects (e.g. see http://llvm.org/pubs/ ) and industrial development projects (see http://llvm.org/Users.html ) ... Plug the dev mtg: http://llvm.org/DevMtgMay2007.html New Features: x. Reid and Sheng contributed IR, optimizer, and interpreter support for arbitrary bitwidth integers which have sizes > 64 bits. This means that LLVM IR can now express operations on 31337-bit wide integers, for example (however, for most people, 128-bit wide integers on 64-bit targets will be the most useful new integer type). Currently neither llvm-gcc nor the native code generators support non-standard width integers. x. The LLVM 1.x "bytecode" format has been replaced with a completely new binary representation, named 'bitcode'. Because we plan to maintain binary compatibility between LLVM 2.x ".bc" files, this is an important change to get right. Bitcode brings a number of advantages to the LLVM over the old bytecode format. It is denser (files are smaller), more extensible, requires less memory to read, is easier to keep backwards compatible (so LLVM 2.5 will read 2.0 .bc files), and has many other nice features. Please see http://llvm.org/ docs/BitCodeFormat.html for more details. x. Christopher Lamb added support for alignment values on load and store instructions, finishing off PR400. This allows the IR to express loads that are not sufficiently aligned (e.g. due to pragma packed) or to capture extra alignment information. x. Roman Samoilov contributed a new MSIL backend to LLVM. llc - march=msil will now turn LLVM into MSIL (".net") bytecode. This is still fairly early development with a number of limitations. x. Anton and Lauro implemented support for 'protected visibility' in ELF. x. Lauro implemented support for Thread Local Storage with the __thread keyword, and added codegen support for Linux on X86 and ARM. x. Anton implemented support for ELF symbol aliases. x. Reid contributed support for 'polymorphic intrinsics', allowing things like llvm.ctpop to work on arbitrary width integers. llvm-gcc Improvements: x. Duncan Sands contributed many enhancements to llvm-gcc, some of which are language independent and others that are aimed towards better Ada support. He made improvements to NON_LVALUE_EXPR, arrays with non-zero base, structs with variable sized fields, VIEW_CONVERT_EXPR, CEIL_DIV_EXPR, and many other things. x. Devang, Duncan and Andrew all contributed many patches to improve "attribute packed" support in the CFE, and handle many other obscure struct layout cases correctly. Optimizer Improvements: x. Devang implemented support for a new LoopPass class, implemented passmanager support for it, and converted existing loop xforms to use it. See: http://llvm.org/docs/WritingAnLLVMPass.html#LoopPass x. Devang contributed a new loop rotation pass, which converts "for loops" into "do/while loops", where the condition is at the bottom of the loop. x. Devang added support that allows ModulePasses to use the result of FunctionPasses. This requires holding multiple FunctionPasses (e.g. dominator info) in memory at a time. x. Owen and Devang both worked to eliminate the [Post]DominatorSet classes from LLVM, switching clients to use the far-more-efficient ETForest class instead. Owen removed the ImmediateDominator class, switching clients to use DominatorTree instead. These changes reduce memory usage and speed up the optimizer. Target-Independent Code Generator Enhancements: x. Jim, Anton and Duncan contributed many enhancements and improvements to C++/Ada zero-cost DWARF exception handling support. While it is not yet solid, it is mostly complete and just in need of continued bug fixes and optimizations at this point. Jim wrote http://llvm.org/docs/ExceptionHandling.html to describe the approach. x. Many bugfixes and other improvements have been made to inline asm support. The two large missing features are support for 80-bit floating point stack registers on X86 (PR879), and support for inline asm in the C backend (PR802). If you run into other issues, please report them. x. Evan implemented a new register scavenger, which is useful for finding free registers after register allocation. This is useful when rewriting frame references on RISC targets, for example. x. LLVM now supports describing target calling conventions explicitly in .td files, reducing the amount of C++ code that needs to be written for a port. x. Evan contributed heuristics to avoid coallescing vregs with very large live ranges to physregs. This effectively pinned the physreg for the entire live range of the vreg, which was very bad for code quality. x. Evan implemented support for very simple (but still very useful) rematerialization in the register allocator, enough to move instructions like "load immediate" and constant pool loads. x. Anton significantly improved 'switch' lowering, improving codegen for sparse switches that have dense subregions, and implemented support for the shift/and trick. x. The code generator now has more accurate and general hooks for describing addressing modes ("isLegalAddressingMode") to optimizations like loop strength reduction and code sinking. x. Dale and Evan contributed several improvements to the Loop Strength Reduction pass, and added support for sinking expressions across blocks to reduce register pressure. x. Evan added support for tracking physreg sub-registers and super- registers in the code generator, as well as extensive register allocator changes to track them. x. Nate contributed initial support for virtreg sub-registers. See PR1350 for more information. Target-Specific Code Generator Enhancements: x. Nicolas Geoffray contributed support for the Linux/ppc ABI, and the linux/ppc JIT is fully functional now. llvm-gcc and static compilation are not fully supported yet though. x. Bill contributed support for the X86 MMX instruction set. x. Dale contributed many enhancements to the ARM constant island pass, making ARM codegen significantly better for large functions. x. Anton fixed several bugs in DWARF debug emission on linux and cygwin/mingw. Debugging basically works on these targets now. x. Lauro contributed support for the ARM AAPCS and EABI ABIs and PIC codegen on arm/linux. x. Dale implemented more aggressive size analysis for ARM inline asm strings. x. Evan added support for the X86-64 large code model to the JIT, which is useful if JIT'd function bodies are more than 2G away from library functions. x. Raul Herbster contributed fixes for DWARF debug info generation on arm/linux. Other Improvements: x. Anton and Reid are working to migrate from CVS to SVN in June: See http://llvm.org/SVNMigration.html This will allow us to host llvm-gcc and llvm in the same repository again! x. Lauro contributed support to llvm-test for running on low-memory or slow machines (make SMALL_PROBLEM_SIZE=1). x. Jeff contributed many portability fixes to the llvm-test testsuite, and has done a great job keeping llvm itself building with MS Visual Studio. ... outro In addition to the features above, this this release also includes hundreds of bug fixes, minor optimization improvements, compile-time speedups, etc. LLVM has literally compiled millions of lines of code in several different environments. http://lists.cs.uiuc.edu/pipermail/llvm-announce/2007-February/ 000021.html If you have any questions or comments, please contact the LLVMdev mailing list (llvmdev at cs.uiuc.edu)! -Chris From baldrick at free.fr Mon May 14 03:34:25 2007 From: baldrick at free.fr (Duncan Sands) Date: Mon, 14 May 2007 10:34:25 +0200 Subject: [LLVMdev] FORTRAN compiler status? In-Reply-To: <46480559.90608@octopus.com.au> References: <46480559.90608@octopus.com.au> Message-ID: <200705141034.25271.baldrick@free.fr> Hi Duraid, > Does anyone know what the latest is w.r.t a FORTRAN front-end for > LLVM? Is anyone expecting to have typical f90/f95 programs compiling to > LLVM this year, or next? (I'm aware of the "NAG hack" and various other > f2c-type approaches, but they give me a strange feeling in my tummy.) support for Fortran will be much easier once LLVM rebases itself on gcc 4.2, which I hope will happen within the next few months. Then it will probably only need a little tender loving care to spring to life. However, we need a volunteer to provide that love... Ciao, Duncan. From lauro.venancio at gmail.com Mon May 14 07:19:47 2007 From: lauro.venancio at gmail.com (Lauro Ramos Venancio) Date: Mon, 14 May 2007 09:19:47 -0300 Subject: [LLVMdev] llvm 2.0 release announcement [draft] In-Reply-To: <03B1371C-3773-41A0-B09A-E7AFE335CF16@apple.com> References: <03B1371C-3773-41A0-B09A-E7AFE335CF16@apple.com> Message-ID: <9c10c9f0705140519j1d759186ufe4cd04b44736221@mail.gmail.com> > > > x. Lauro implemented support for Thread Local Storage with the > __thread keyword, and added codegen support for Linux on X86 and ARM. Thread Local Storage is not fully functional on ARM because the ARM TLS llvm-gcc patch wasn't applied yet. So, I think the __thread keyword support for ARM will appear on LLVM 2.1. x. Lauro contributed support for the ARM AAPCS and EABI ABIs and > PIC codegen on arm/linux. ARM AAPCS and EABI are the same ABI. AAPCS or EABI => arm-linux-gnueabi APCS or OABI => arm-linux-gnu and arm-apple-darwin Lauro -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20070514/95f5949e/attachment.html From jeffc at jolt-lang.org Mon May 14 09:34:29 2007 From: jeffc at jolt-lang.org (Jeff Cohen) Date: Mon, 14 May 2007 07:34:29 -0700 Subject: [LLVMdev] llvm 2.0 release announcement [draft] In-Reply-To: <03B1371C-3773-41A0-B09A-E7AFE335CF16@apple.com> References: <03B1371C-3773-41A0-B09A-E7AFE335CF16@apple.com> Message-ID: <46487375.7010109@jolt-lang.org> Chris Lattner wrote: > x. Roman Samoilov contributed a new MSIL backend to LLVM. llc - > march=msil will now turn LLVM into MSIL (".net") bytecode. This is > still fairly early development with a number of limitations. > This ought not be advertised to the world. It is not useful for any purpose. Not only can it not do virtual method calls, as I previously pointed out, it can't even instantiate objects! And there is a good reason why the implementation cannot do so: it is extremely difficult to recover high-level MSIL semantics from low-level LLVM IR. I am not convinced it is even possible. It's as hard as reconstructing a C++ class declaration from LLVM IR. > x. Evan added support for the X86-64 large code model to the JIT, > which is useful if JIT'd function bodies are more than 2G away from > library functions. > Not true. See PR1299, which still hasn't been fixed. From nicolas.geoffray at lip6.fr Mon May 14 09:58:56 2007 From: nicolas.geoffray at lip6.fr (Nicolas Geoffray) Date: Mon, 14 May 2007 16:58:56 +0200 Subject: [LLVMdev] Compiling llvm-gcc in linux/ppc Message-ID: <46487930.8090102@lip6.fr> Hi everyone, I am using linux/ppc and after porting llvm's jit for this architecture, I am currently trying to compile llvm-gcc on it. I have gcc 4.1.1 and use llvm-gcc from cvs. Compilation fails and the message is: gcc -O2 -DIN_GCC -DDEFAULT_TARGET_MACHINE=\"powerpc-unknown-linux-gnu\" -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -fno-common -DHAVE_CONFIG_H -o f771 f/bad.o f/bit.o f/bld.o f/com.o f/data.o f/equiv.o f/expr.o f/global.o f/implic.o f/info.o f/intrin.o f/lab.o f/lex.o f/malloc.o f/name.o f/parse.o f/src.o f/st.o f/sta.o f/stb.o f/stc.o f/std.o f/ste.o f/storag.o f/stp.o f/str.o f/sts.o f/stt.o f/stu.o f/stv.o f/stw.o f/symbol.o f/target.o f/top.o f/type.o f/where.o main.o libbackend.a ../libiberty/libiberty.a libbackend.a(llvm-out.o): In function `llvm_c_expand_body': llvm-out.c:(.text+0x1c2): undefined reference to `lang_expand_function_end' llvm-out.c:(.text+0x1c6): undefined reference to `lang_expand_function_end' libbackend.a(llvm-out.o): In function `llvm_init_asm_output': llvm-out.c:(.text+0x70e): undefined reference to `c_language' llvm-out.c:(.text+0x716): undefined reference to `c_language' llvm-out.c:(.text+0x7ba): undefined reference to `c_language' llvm-out.c:(.text+0x7c2): undefined reference to `c_language' llvm-out.c:(.text+0x7ea): undefined reference to `c_language' libbackend.a(llvm-expand.o): In function `llvm_emit_local_var': llvm-expand.c:(.text+0x16f48): undefined reference to `stmts_are_full_exprs_p' llvm-expand.c:(.text+0x16f60): undefined reference to `stmts_are_full_exprs_p' libbackend.a(llvm-expand.o): In function `genllvm_decl_stmt': llvm-expand.c:(.text+0x203a6): undefined reference to `lang_expand_decl_stmt' llvm-expand.c:(.text+0x203aa): undefined reference to `lang_expand_decl_stmt' llvm-expand.c:(.text+0x204d8): undefined reference to `anon_aggr_type_p' libbackend.a(llvm-expand.o): In function `llvm_expand_stmt': llvm-expand.c:(.text+0x20c98): undefined reference to `stmts_are_full_exprs_p' llvm-expand.c:(.text+0x20ca4): undefined reference to `prep_stmt' llvm-expand.c:(.text+0x20d64): undefined reference to `current_stmt_tree' llvm-expand.c:(.text+0x20ea4): undefined reference to `stmts_are_full_exprs_p' llvm-expand.c:(.text+0x20ecc): undefined reference to `stmts_are_full_exprs_p' llvm-expand.c:(.text+0x210fc): undefined reference to `stmts_are_full_exprs_p' llvm-expand.c:(.text+0x21108): undefined reference to `prep_stmt' llvm-expand.c:(.text+0x21118): undefined reference to `current_stmt_tree' libbackend.a(llvm-expand.o): In function `genllvm_for_stmt': llvm-expand.c:(.text+0x227e8): undefined reference to `stmts_are_full_exprs_p' llvm-expand.c:(.text+0x2283c): undefined reference to `stmts_are_full_exprs_p' libbackend.a(tree-inline.o): In function `copy_tree_r': tree-inline.c:(.text+0x2e2): undefined reference to `statement_code_p' tree-inline.c:(.text+0x2e6): undefined reference to `statement_code_p' libbackend.a(tree-inline.o): In function `walk_tree': tree-inline.c:(.text+0x436): undefined reference to `statement_code_p' tree-inline.c:(.text+0x43a): undefined reference to `statement_code_p' tree-inline.c:(.text+0x546): undefined reference to `statement_code_p' libbackend.a(tree-inline.o):tree-inline.c:(.text+0x54a): more undefined references to `statement_code_p' follow libbackend.a(tree-inline.o): In function `copy_body_r': tree-inline.c:(.text+0x2620): undefined reference to `build_stmt' tree-inline.c:(.text+0x26d4): undefined reference to `build_stmt' libbackend.a(tree-inline.o): In function `expand_call_inline': tree-inline.c:(.text+0x37a0): undefined reference to `build_stmt' tree-inline.c:(.text+0x3808): undefined reference to `build_stmt' tree-inline.c:(.text+0x386c): undefined reference to `build_stmt' libbackend.a(tree-inline.o):tree-inline.c:(.text+0x3c44): more undefined references to `build_stmt' follow libbackend.a(tree-inline.o): In function `expand_call_inline': tree-inline.c:(.text+0x3d54): undefined reference to `decl_constant_value' tree-inline.c:(.text+0x4108): undefined reference to `build_stmt' tree-inline.c:(.text+0x4390): undefined reference to `build_stmt' tree-inline.c:(.text+0x446c): undefined reference to `build_stmt' tree-inline.c:(.text+0x44e4): undefined reference to `build_stmt' tree-inline.c:(.text+0x4b78): undefined reference to `build_stmt' libbackend.a(tree-inline.o):tree-inline.c:(.text+0x4b90): more undefined references to `build_stmt' follow collect2: ld returned 1 exit status make[1]: *** [f771] Error 1 make[1]: Leaving directory `/home/varth/project/llvm-cvs/llvm-gcc/gcc' make: *** [all-gcc] Error 2 If anyone has a clue... Best, Nicolas From sabre at nondot.org Mon May 14 13:13:09 2007 From: sabre at nondot.org (Chris Lattner) Date: Mon, 14 May 2007 11:13:09 -0700 (PDT) Subject: [LLVMdev] Compiling llvm-gcc in linux/ppc In-Reply-To: <46487930.8090102@lip6.fr> References: <46487930.8090102@lip6.fr> Message-ID: On Mon, 14 May 2007, Nicolas Geoffray wrote: > Hi everyone, I am using linux/ppc and after porting llvm's jit for this > architecture, I am currently trying to compile llvm-gcc on it. > > I have gcc 4.1.1 and use llvm-gcc from cvs. This looks like you're compiling llvm-gcc3, which is quite dead by now. Please follow these instructions: http://llvm.org/docs/CFEBuildInstrs.html In particular, following the instructions in README.LLVM is very important. Building the fortran front-end, for example, won't work. -Chris > Compilation fails and the message is: > > gcc -O2 -DIN_GCC > -DDEFAULT_TARGET_MACHINE=\"powerpc-unknown-linux-gnu\" -W -Wall > -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic > -Wno-long-long -fno-common -DHAVE_CONFIG_H -o f771 f/bad.o f/bit.o > f/bld.o f/com.o f/data.o f/equiv.o f/expr.o f/global.o f/implic.o > f/info.o f/intrin.o f/lab.o f/lex.o f/malloc.o f/name.o f/parse.o > f/src.o f/st.o f/sta.o f/stb.o f/stc.o f/std.o f/ste.o f/storag.o > f/stp.o f/str.o f/sts.o f/stt.o f/stu.o f/stv.o f/stw.o f/symbol.o > f/target.o f/top.o f/type.o f/where.o main.o libbackend.a > ../libiberty/libiberty.a > libbackend.a(llvm-out.o): In function `llvm_c_expand_body': > llvm-out.c:(.text+0x1c2): undefined reference to `lang_expand_function_end' > llvm-out.c:(.text+0x1c6): undefined reference to `lang_expand_function_end' > libbackend.a(llvm-out.o): In function `llvm_init_asm_output': > llvm-out.c:(.text+0x70e): undefined reference to `c_language' > llvm-out.c:(.text+0x716): undefined reference to `c_language' > llvm-out.c:(.text+0x7ba): undefined reference to `c_language' > llvm-out.c:(.text+0x7c2): undefined reference to `c_language' > llvm-out.c:(.text+0x7ea): undefined reference to `c_language' > libbackend.a(llvm-expand.o): In function `llvm_emit_local_var': > llvm-expand.c:(.text+0x16f48): undefined reference to > `stmts_are_full_exprs_p' > llvm-expand.c:(.text+0x16f60): undefined reference to > `stmts_are_full_exprs_p' > libbackend.a(llvm-expand.o): In function `genllvm_decl_stmt': > llvm-expand.c:(.text+0x203a6): undefined reference to > `lang_expand_decl_stmt' > llvm-expand.c:(.text+0x203aa): undefined reference to > `lang_expand_decl_stmt' > llvm-expand.c:(.text+0x204d8): undefined reference to `anon_aggr_type_p' > libbackend.a(llvm-expand.o): In function `llvm_expand_stmt': > llvm-expand.c:(.text+0x20c98): undefined reference to > `stmts_are_full_exprs_p' > llvm-expand.c:(.text+0x20ca4): undefined reference to `prep_stmt' > llvm-expand.c:(.text+0x20d64): undefined reference to `current_stmt_tree' > llvm-expand.c:(.text+0x20ea4): undefined reference to > `stmts_are_full_exprs_p' > llvm-expand.c:(.text+0x20ecc): undefined reference to > `stmts_are_full_exprs_p' > llvm-expand.c:(.text+0x210fc): undefined reference to > `stmts_are_full_exprs_p' > llvm-expand.c:(.text+0x21108): undefined reference to `prep_stmt' > llvm-expand.c:(.text+0x21118): undefined reference to `current_stmt_tree' > libbackend.a(llvm-expand.o): In function `genllvm_for_stmt': > llvm-expand.c:(.text+0x227e8): undefined reference to > `stmts_are_full_exprs_p' > llvm-expand.c:(.text+0x2283c): undefined reference to > `stmts_are_full_exprs_p' > libbackend.a(tree-inline.o): In function `copy_tree_r': > tree-inline.c:(.text+0x2e2): undefined reference to `statement_code_p' > tree-inline.c:(.text+0x2e6): undefined reference to `statement_code_p' > libbackend.a(tree-inline.o): In function `walk_tree': > tree-inline.c:(.text+0x436): undefined reference to `statement_code_p' > tree-inline.c:(.text+0x43a): undefined reference to `statement_code_p' > tree-inline.c:(.text+0x546): undefined reference to `statement_code_p' > libbackend.a(tree-inline.o):tree-inline.c:(.text+0x54a): more undefined > references to `statement_code_p' follow > libbackend.a(tree-inline.o): In function `copy_body_r': > tree-inline.c:(.text+0x2620): undefined reference to `build_stmt' > tree-inline.c:(.text+0x26d4): undefined reference to `build_stmt' > libbackend.a(tree-inline.o): In function `expand_call_inline': > tree-inline.c:(.text+0x37a0): undefined reference to `build_stmt' > tree-inline.c:(.text+0x3808): undefined reference to `build_stmt' > tree-inline.c:(.text+0x386c): undefined reference to `build_stmt' > libbackend.a(tree-inline.o):tree-inline.c:(.text+0x3c44): more undefined > references to `build_stmt' follow > libbackend.a(tree-inline.o): In function `expand_call_inline': > tree-inline.c:(.text+0x3d54): undefined reference to `decl_constant_value' > tree-inline.c:(.text+0x4108): undefined reference to `build_stmt' > tree-inline.c:(.text+0x4390): undefined reference to `build_stmt' > tree-inline.c:(.text+0x446c): undefined reference to `build_stmt' > tree-inline.c:(.text+0x44e4): undefined reference to `build_stmt' > tree-inline.c:(.text+0x4b78): undefined reference to `build_stmt' > libbackend.a(tree-inline.o):tree-inline.c:(.text+0x4b90): more undefined > references to `build_stmt' follow > collect2: ld returned 1 exit status > make[1]: *** [f771] Error 1 > make[1]: Leaving directory `/home/varth/project/llvm-cvs/llvm-gcc/gcc' > make: *** [all-gcc] Error 2 > > If anyone has a clue... > > Best, > Nicolas > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > -Chris -- http://nondot.org/sabre/ http://llvm.org/ From sabre at nondot.org Tue May 15 00:13:02 2007 From: sabre at nondot.org (Chris Lattner) Date: Mon, 14 May 2007 22:13:02 -0700 (PDT) Subject: [LLVMdev] llvm 2.0 release announcement [draft] In-Reply-To: <46487375.7010109@jolt-lang.org> References: <03B1371C-3773-41A0-B09A-E7AFE335CF16@apple.com> <46487375.7010109@jolt-lang.org> Message-ID: On Mon, 14 May 2007, Jeff Cohen wrote: > Chris Lattner wrote: >> x. Roman Samoilov contributed a new MSIL backend to LLVM. llc - >> march=msil will now turn LLVM into MSIL (".net") bytecode. This is still >> fairly early development with a number of limitations. > This ought not be advertised to the world. It is not useful for any purpose. Jeff, I'm well aware of your opinions in this matter. > Not only can it not do virtual method calls, as I previously pointed out, it > can't even instantiate objects! And there is a good reason why the > implementation cannot do so: it is extremely difficult to recover high-level > MSIL semantics from low-level LLVM IR. I am not convinced it is even > possible. It's as hard as reconstructing a C++ class declaration from LLVM > IR. The full power of MSIL isn't available through the msil backend, and it is not very useful if you're converting from C code. I say "This is still fairly early development with a number of limitations.", which I believe is accurate. Even though you apparently don't like this work, please don't disparage it. Other people have put time and effort into it, and it could grow to be an important component in the future. >> x. Evan added support for the X86-64 large code model to the JIT, which >> is useful if JIT'd function bodies are more than 2G away from library >> functions. > Not true. See PR1299, which still hasn't been fixed. Actually, it is true - PR1299 not being fixed does not mean the work wasn't done. I did not claim that he fixed every possible x86-64 jit bug, certainly not on platforms we don't have available to test. I asked Evan to look into this PR, but if you'd like it fixed, the only certain wait to get it fixed is to do it yourself (or pay someone else to do it, I suppose). -Chris -- http://nondot.org/sabre/ http://llvm.org/ From tonic at nondot.org Tue May 15 03:23:32 2007 From: tonic at nondot.org (Tanya M. Lattner) Date: Tue, 15 May 2007 01:23:32 -0700 (PDT) Subject: [LLVMdev] 2.0 Pre-release tarballs online Message-ID: I've uploaded the 2.0 pre-release to this location: http://llvm.org/prereleases/2.0/ If you have free time and would like to help test this release, please download the appropriate tarballs from the website. Here are a few ways you can help test this release: 1) Download llvm-gcc4 binary and llvm. Compile and run make check. 2) Download llvm-gcc4 binary, llvm, and llvm-test. Compile, run make check, and do "make ENABLE_OPTIMIZED=1 TEST=nightly report" in llvm-test. 3) Compile llvm-gcc4 and llvm from source. Run 'make check'. 4) Compile llvm-gcc4 and llvm from source. Run 'make check' and do a 'make ENABLE_OPTIMIZED=1 TEST=nightly report' in llvm-test. It would also be helpful for someone to compile/test with objdir != srcdir. The 2.0 release defaults to a Release build, but you are welcome to test with a Debug build as well. When reporting your results, please email the list and mention what platform, which option you chose (1, 2, 3, or 4), and if you made any configure changes (objdir != srcdir, or Debug build). Include the dejagnu test log or the nightly test report. Thanks, Tanya Lattner From evan.cheng at apple.com Tue May 15 03:29:08 2007 From: evan.cheng at apple.com (Evan Cheng) Date: Tue, 15 May 2007 01:29:08 -0700 Subject: [LLVMdev] llvm 2.0 release announcement [draft] In-Reply-To: References: <03B1371C-3773-41A0-B09A-E7AFE335CF16@apple.com> <46487375.7010109@jolt-lang.org> Message-ID: On May 14, 2007, at 10:13 PM, Chris Lattner wrote: > >>> x. Evan added support for the X86-64 large code model to the >>> JIT, which >>> is useful if JIT'd function bodies are more than 2G away from >>> library >>> functions. > >> Not true. See PR1299, which still hasn't been fixed. It's fine with me if we don't say anything about x86-64 large code model. There was enough to get the JIT working on Mac. But I am relying on others to test / fix other platforms. There are plenty left to do before we can claim true large code model support. > > Actually, it is true - PR1299 not being fixed does not mean the work > wasn't done. I did not claim that he fixed every possible x86-64 > jit bug, > certainly not on platforms we don't have available to test. > > I asked Evan to look into this PR, but if you'd like it fixed, the > only > certain wait to get it fixed is to do it yourself (or pay someone > else to > do it, I suppose). I don't have a freebsd box to test. Please reduce the test case to a .bc file and I'll be happy to look at it. Evan > > -Chris > > -- > http://nondot.org/sabre/ > http://llvm.org/ > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From nicolas.geoffray at lip6.fr Tue May 15 04:38:46 2007 From: nicolas.geoffray at lip6.fr (Nicolas Geoffray) Date: Tue, 15 May 2007 11:38:46 +0200 Subject: [LLVMdev] Compiling llvm-gcc in linux/ppc In-Reply-To: References: <46487930.8090102@lip6.fr> Message-ID: <46497FA6.8000801@lip6.fr> Chris Lattner wrote: > > This looks like you're compiling llvm-gcc3, which is quite dead by now. > Please follow these instructions: > http://llvm.org/docs/CFEBuildInstrs.html > > Oups, sorry for that. Here is the error message with the latest svn version: gcc -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition -DHAVE_CONFIG_H -DENABLE_LLVM -D__STDC_LIMIT_MACROS -I. -I. -I../../trunk/gcc -I../../trunk/gcc/. -I../../trunk/gcc/../include -I../../trunk/gcc/../libcpp/include -I/home/varth/project/llvm-cvs/llvm/include -I/usr/local/home/varth/project/llvm-cvs/llvm/include ../../trunk/gcc/stor-layout.c -o stor-layout.o ../../trunk/gcc/stor-layout.c:450:25: error: macro "ADJUST_FIELD_ALIGN" passed 3 arguments, but takes just 2 ../../trunk/gcc/stor-layout.c: In function 'layout_decl': ../../trunk/gcc/stor-layout.c:449: error: 'ADJUST_FIELD_ALIGN' undeclared (first use in this function) ../../trunk/gcc/stor-layout.c:449: error: (Each undeclared identifier is reported only once ../../trunk/gcc/stor-layout.c:449: error: for each function it appears in.) ../../trunk/gcc/stor-layout.c:711:43: error: macro "ADJUST_FIELD_ALIGN" passed 3 arguments, but takes just 2 ../../trunk/gcc/stor-layout.c: In function 'update_alignment_for_field': ../../trunk/gcc/stor-layout.c:708: error: 'ADJUST_FIELD_ALIGN' undeclared (first use in this function) ../../trunk/gcc/stor-layout.c:760:41: error: macro "ADJUST_FIELD_ALIGN" passed 3 arguments, but takes just 2 ../../trunk/gcc/stor-layout.c:994:44: error: macro "ADJUST_FIELD_ALIGN" passed 3 arguments, but takes just 2 ../../trunk/gcc/stor-layout.c: In function 'place_field': ../../trunk/gcc/stor-layout.c:991: error: 'ADJUST_FIELD_ALIGN' undeclared (first use in this function) ../../trunk/gcc/stor-layout.c:1031:44: error: macro "ADJUST_FIELD_ALIGN" passed 3 arguments, but takes just 2 make[1]: *** [stor-layout.o] Error 1 make[1]: Leaving directory `/home/varth/project/llvm-cvs/llvm-gcc4/obj/gcc' make: *** [all-gcc] Error 2 I looked a bit at the source, and the gcc/config/darwin.h declares a ADJUST_FIELD_ALIGN with two arguments whereas all other back-ends that declare ADJUST_FIELD_ALIGN have only two arguments. And it seems that stor-layout.c assumes that if we have ADJUST_FIELD_ALIGN defined, then we're on darwin. Nicolas From tonic at nondot.org Tue May 15 14:04:18 2007 From: tonic at nondot.org (Tanya M. Lattner) Date: Tue, 15 May 2007 12:04:18 -0700 (PDT) Subject: [LLVMdev] 2.0 Pre-release tarballs online In-Reply-To: References: Message-ID: I forgot to mention that all testing should be completed by May 20th 5pm PDT. -Tanya On Tue, 15 May 2007, Tanya M. Lattner wrote: > > I've uploaded the 2.0 pre-release to this location: > http://llvm.org/prereleases/2.0/ > > If you have free time and would like to help test this release, please > download the appropriate tarballs from the website. > > Here are a few ways you can help test this release: > > 1) Download llvm-gcc4 binary and llvm. Compile and run make check. > > 2) Download llvm-gcc4 binary, llvm, and llvm-test. Compile, run make > check, and do "make ENABLE_OPTIMIZED=1 TEST=nightly report" in llvm-test. > > 3) Compile llvm-gcc4 and llvm from source. Run 'make check'. > > 4) Compile llvm-gcc4 and llvm from source. Run 'make check' and do a 'make > ENABLE_OPTIMIZED=1 TEST=nightly report' in llvm-test. > > It would also be helpful for someone to compile/test with objdir != srcdir. > The 2.0 release defaults to a Release build, but you are welcome > to test with a Debug build as well. > > When reporting your results, please email the list and mention what > platform, which option you chose (1, 2, 3, or 4), and if you made any > configure changes (objdir != srcdir, or Debug build). Include the dejagnu > test log or the nightly test report. > > Thanks, > Tanya Lattner > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From michael.mccracken at gmail.com Tue May 15 15:15:41 2007 From: michael.mccracken at gmail.com (Michael McCracken) Date: Tue, 15 May 2007 13:15:41 -0700 Subject: [LLVMdev] FORTRAN compiler status? In-Reply-To: <200705141034.25271.baldrick@free.fr> References: <46480559.90608@octopus.com.au> <200705141034.25271.baldrick@free.fr> Message-ID: I just noticed this - I can't promise any particular amount of TLC, but I'll certainly be giving the Fortran front-end some attention as soon as LLVM moves to gcc 4.2. For future reference, does anyone know of a good free Fortran compiler test suite? Cheers, -mike On 5/14/07, Duncan Sands wrote: > Hi Duraid, > > > Does anyone know what the latest is w.r.t a FORTRAN front-end for > > LLVM? Is anyone expecting to have typical f90/f95 programs compiling to > > LLVM this year, or next? (I'm aware of the "NAG hack" and various other > > f2c-type approaches, but they give me a strange feeling in my tummy.) > > support for Fortran will be much easier once LLVM rebases itself on > gcc 4.2, which I hope will happen within the next few months. Then it > will probably only need a little tender loving care to spring to life. > However, we need a volunteer to provide that love... > > Ciao, > > Duncan. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > -- Michael McCracken UCSD CSE PhD Candidate research: http://www.cse.ucsd.edu/~mmccrack/ misc: http://michael-mccracken.net/wp/ From rafael.espindola at gmail.com Tue May 15 15:23:10 2007 From: rafael.espindola at gmail.com (=?UTF-8?Q?Rafael_Esp=C3=ADndola?=) Date: Tue, 15 May 2007 21:23:10 +0100 Subject: [LLVMdev] Developer Pictures Wanted For DevMtg In-Reply-To: <1176378371.23191.35.camel@bashful.x10sys.com> References: <1176378371.23191.35.camel@bashful.x10sys.com> Message-ID: <564d96fb0705151323k41fa1436hb8a574defcf02a10@mail.gmail.com> > If you're a developer and so inclined, consider sending in a picture now > so that Developer Meeting attendees can start to match names with faces. > This will be the first time a lot of us will be face to face. Better late then never :-) Cheers, Rafael -------------- next part -------------- A non-text attachment was scrubbed... Name: 0120-173901.jpg Type: image/jpeg Size: 56504 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20070515/3671b1fc/attachment-0001.jpg From baldrick at free.fr Wed May 16 01:56:43 2007 From: baldrick at free.fr (Duncan Sands) Date: Wed, 16 May 2007 08:56:43 +0200 Subject: [LLVMdev] FORTRAN compiler status? In-Reply-To: References: <46480559.90608@octopus.com.au> <200705141034.25271.baldrick@free.fr> Message-ID: <200705160856.43663.baldrick@free.fr> On Tuesday 15 May 2007 22:15:41 Michael McCracken wrote: > I just noticed this - I can't promise any particular amount of TLC, but > I'll certainly be giving the Fortran front-end some attention as soon as > LLVM moves to gcc 4.2. > > For future reference, does anyone know of a good free Fortran compiler > test suite? The gcc testsuite has many Fortran tests. Ciao, Duncan. From basile at starynkevitch.net Wed May 16 07:06:03 2007 From: basile at starynkevitch.net (Basile STARYNKEVITCH) Date: Wed, 16 May 2007 14:06:03 +0200 Subject: [LLVMdev] tiny compilation error with g++ 4.1.3 Message-ID: <20070516120603.GA28694@ours.starynkevitch.net> Hello All File llvm/lib/ExecutionEngine/Interpreter/Execution.cpp (cvs rev 1.182) fails to compile with g++ 4.1.3 (Debian/Sid/AMD64 system) make[2]: Leaving directory `/usr/src/Lang/llvm/_Obj64/lib/Target' make[2]: Entering directory `/usr/src/Lang/llvm/_Obj64/lib/ExecutionEngine' make[3]: Entering directory `/usr/src/Lang/llvm/_Obj64/lib/ExecutionEngine/Interpreter' llvm[3]: Compiling Execution.cpp for Debug build /usr/src/Lang/llvm/lib/ExecutionEngine/Interpreter/Execution.cpp: In function 'void PrintGenericValue(const llvm::GenericValue&, const llvm::Type*)': /usr/src/Lang/llvm/lib/ExecutionEngine/Interpreter/Execution.cpp:1347: error: cast from 'void*' to 'unsigned int' loses precision The trivial patch which works for me is to use intptr_t instead of unsigned, hence replacing the faulty line with case Type::PointerTyID: DOUT << "void* " << (intptr_t)(Val.PointerVal); break; Regards -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basilestarynkevitchnet mobile: +33 6 8501 2359 8, rue de la Fa?encerie, 92340 Bourg La Reine, France *** opinions {are only mines, sont seulement les miennes} *** From fbrandne at mail.tuwien.ac.at Wed May 16 07:15:27 2007 From: fbrandne at mail.tuwien.ac.at (Florian Brandner) Date: Wed, 16 May 2007 14:15:27 +0200 Subject: [LLVMdev] instruction selector failure Message-ID: <464AF5DF.1010608@mail.tuwien.ac.at> hi, i found a problem in LLVM regarding the matching of 'Constant' nodes in the instruction selector. the testcase is for x86, but similar testcases for the other architectures (e.g. ppc) should be easy to create. i'm using the llvm-gcc 2.0 prerelease binary package. here is the testcase: int foo(int bar) { asm("movl %1, %0" : "=r"(bar) : "i"(5)); return 11; } the problem here is, that the constant node '11' is shared by a CopyToReg node (for the return) and the INLINEASM node. the INLINEASM node uses the constant as a flag indicating that an immediate operand (5 in this case) follows. the instruction selector rewrites the constant node into a MOV32ri. which causes the scheduler to crash with the following error message: [brandner:~/tmp:720] /raid0/brandner/llvm-2.0/llvm-gcc4-2.0-x86-linux-RHEL4/bin/llvm-gcc -c test.c -O1 cc1: /mounts/zion/disks/0/localhome/tbrethou/llvm/include/llvm/Support/Casting.h:199: typename llvm::cast_retty::ret_type llvm::cast(const Y&) [with X = llvm::ConstantSDNode, Y = llvm::SDOperand]: Assertion `isa(Val) && "cast() argument of incompatible type!"' failed. test.c:4: internal compiler error: Aborted Please submit a full bug report, with preprocessed source if appropriate. See for instructions. a backtrace in cc1 shows: (gdb) bt #0 0xf7da55df in raise () from /lib32/libc.so.6 #1 0xf7da6b13 in abort () from /lib32/libc.so.6 #2 0xf7d9edac in __assert_fail () from /lib32/libc.so.6 #3 0x085c63f4 in llvm::ScheduleDAG::EmitNode () (gdb) i would like to fix this bug, but it is hard to tell the real source of the problem: 1.) it could be an error during the legalization. sharing the constant node could be prevented. this would not cause the instruction selector to rewrite the constant node. 2.) the error is in the instruction selector, which should duplicate the constant node. 3.) the instruction selector should not select flags of INLINE and CALL nodes. instead it should just copy the original nodes. i would prefer solution 3, any suggestions on this? cheers, florian From basile at starynkevitch.net Wed May 16 08:09:20 2007 From: basile at starynkevitch.net (Basile STARYNKEVITCH) Date: Wed, 16 May 2007 15:09:20 +0200 Subject: [LLVMdev] generating ELF shared object, C code, from a module like Fibionnaci Message-ID: <20070516130920.GA29730@ours.starynkevitch.net> Hello Apparently the file llvm/examples/Fibonacci/fibonacci.cpp generate JIT code without explicitly doing any pass (but I suppose that internally, compiler passes are running!) - is there a dissymetry between JIT machine code generation in memory, and C or ELF shared object generation in files? I thought that all these shared a lot of LLVM infrastructure and happen similarily! Also, the llvm/tools/llc/llcp.ccp file explicitly need passes and a pass manager to generate .so and .c files I would like to understand precisely how to patch the fibionnaci example to generate an ELF shared object or a C file, in addition of the JIT-ed code in memory. May it should become a FAQ. I also don't understand what is the LLVM meaning of inter-module linking... To suggest an example, one could add code to fibionacci which load a bitcode from a file, JIT it, and uses a printing routine there to print fib(10). Actually, I miss a document or wiki explaining how to use (without extending it) LLVM to generate code (in variety of ways, including C, ELF shared object, JIT-ed code in memory) from within an application. Just a simple example like fibionnaci is great! My dream would be some tutorial documentation with working actual code snippets... in the spirit of e.g. http://www.gnu.org/software/lightning/manual/html_node/Fibonacci.html which documents an example similar to llvm/examples/Fibonacci/fibonacci.cpp I would like the same for LLVM, emitting JIT code, ELF shared library, C file.... Maybe such a documentation exist (hopefully up to date for LLVM2.0!) but I did not found it yet! Perhaps just linking the example source files from the web site could be a good idea... The doxygen documentation is very good, but does not separate enough what an LLVM user (some developer using LLVM in his own program) should see and what an LLVM developer (someone enhancing LLVM) should in addition know. I find LLVM great, but quite hard to grasp. Regards. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basilestarynkevitchnet mobile: +33 6 8501 2359 8, rue de la Fa?encerie, 92340 Bourg La Reine, France *** opinions {are only mines, sont seulement les miennes} *** From rspencer at reidspencer.com Wed May 16 11:40:25 2007 From: rspencer at reidspencer.com (Reid Spencer) Date: Wed, 16 May 2007 09:40:25 -0700 Subject: [LLVMdev] tiny compilation error with g++ 4.1.3 In-Reply-To: <20070516120603.GA28694@ours.starynkevitch.net> References: <20070516120603.GA28694@ours.starynkevitch.net> Message-ID: <1179333625.1233.414.camel@bashful.x10sys.com> Hi Basile, On Wed, 2007-05-16 at 14:06 +0200, Basile STARYNKEVITCH wrote: > Hello All > > File llvm/lib/ExecutionEngine/Interpreter/Execution.cpp (cvs rev 1.182) > fails to compile with g++ 4.1.3 (Debian/Sid/AMD64 system) > > make[2]: Leaving directory `/usr/src/Lang/llvm/_Obj64/lib/Target' > make[2]: Entering directory `/usr/src/Lang/llvm/_Obj64/lib/ExecutionEngine' > make[3]: Entering directory `/usr/src/Lang/llvm/_Obj64/lib/ExecutionEngine/Interpreter' > llvm[3]: Compiling Execution.cpp for Debug build > /usr/src/Lang/llvm/lib/ExecutionEngine/Interpreter/Execution.cpp: In function 'void PrintGenericValue(const llvm::GenericValue&, const llvm::Type*)': > /usr/src/Lang/llvm/lib/ExecutionEngine/Interpreter/Execution.cpp:1347: error: cast from 'void*' to 'unsigned int' loses precision > > > The trivial patch which works for me is to use intptr_t instead of unsigned, hence replacing the faulty line with > > case Type::PointerTyID: DOUT << "void* " << (intptr_t)(Val.PointerVal); break; Yup. I made this change. Thanks, Reid. > > Regards From tonic at nondot.org Wed May 16 13:01:19 2007 From: tonic at nondot.org (Tanya M. Lattner) Date: Wed, 16 May 2007 11:01:19 -0700 (PDT) Subject: [LLVMdev] generating ELF shared object, C code, from a module like Fibionnaci In-Reply-To: <20070516130920.GA29730@ours.starynkevitch.net> References: <20070516130920.GA29730@ours.starynkevitch.net> Message-ID: > Actually, I miss a document or wiki explaining how to use (without extending > it) LLVM to generate code (in variety of ways, including C, ELF shared > object, JIT-ed code in memory) from within an application. Just a simple > example like fibionnaci is great! I believe this is the only tutorial we have on how to use llvm in a variety of ways: http://llvm.org/docs/GettingStarted.html#tutorial We welcome any changes to this document that you think would be helpful. -Tanya > > My dream would be some tutorial documentation with working actual code > snippets... in the spirit of e.g. > http://www.gnu.org/software/lightning/manual/html_node/Fibonacci.html which > documents an example similar to llvm/examples/Fibonacci/fibonacci.cpp I > would like the same for LLVM, emitting JIT code, ELF shared library, C > file.... Maybe such a documentation exist (hopefully up to date for > LLVM2.0!) but I did not found it yet! Perhaps just linking the example > source files from the web site could be a good idea... > > The doxygen documentation is very good, but does not separate enough what an > LLVM user (some developer using LLVM in his own program) should see and what > an LLVM developer (someone enhancing LLVM) should in addition know. > > I find LLVM great, but quite hard to grasp. > > Regards. > From rspencer at reidspencer.com Wed May 16 12:19:21 2007 From: rspencer at reidspencer.com (Reid Spencer) Date: Wed, 16 May 2007 17:19:21 +0000 Subject: [LLVMdev] generating ELF shared object, C code, from a module like Fibionnaci In-Reply-To: <20070516130920.GA29730@ours.starynkevitch.net> References: <20070516130920.GA29730@ours.starynkevitch.net> Message-ID: <1179335961.1233.424.camel@bashful.x10sys.com> On Wed, 2007-05-16 at 15:09 +0200, Basile STARYNKEVITCH wrote: > Hello > > Apparently the file llvm/examples/Fibonacci/fibonacci.cpp generate JIT code > without explicitly doing any pass (but I suppose that internally, compiler > passes are running!) Very few. There are passes that run in order to do the code generation. But, none of the optimization passes are run. > - is there a dissymetry between JIT machine code > generation in memory, and C or ELF shared object generation in files? Generation of native assembly, ELF and JIT are very similar except for the final emission stage where the code is actually produced. The C Backend is completely different, it shares nothing with the other code generators. > I > thought that all these shared a lot of LLVM infrastructure and happen > similarily! They do, but the optimization passes are at a level above code generation. They operate on the generic mid-level IR. Consequently code generated by any back end can have the same optimizations applied. The only thing missing is that fibonacci example just isn't doing the optimization part. It could be enhanced to do that, however. > > Also, the llvm/tools/llc/llcp.ccp file explicitly need passes and a pass > manager to generate .so and .c files That's right. > > I would like to understand precisely how to patch the fibionnaci example to > generate an ELF shared object or a C file, in addition of the JIT-ed code in > memory. May it should become a FAQ. I suggest you study llc and lib/CodeGen and lib/Target more carefully. AFAIK the ELF writer is not working on all platforms (I think it only works on one) and its being enhanced contemporaneously. > I also don't understand what is the LLVM meaning of inter-module linking... > To suggest an example, one could add code to fibionacci which load a bitcode > from a file, JIT it, and uses a printing routine there to print fib(10). Code in LLVM is bundled into a "Module" concept (somewhat like a translation unit). inter-module linking is simply linking together those modules (i.e. multiple bitcode files). > > Actually, I miss a document or wiki explaining how to use (without extending > it) LLVM to generate code (in variety of ways, including C, ELF shared > object, JIT-ed code in memory) from within an application. Just a simple > example like fibionnaci is great! > > My dream would be some tutorial documentation with working actual code > snippets... in the spirit of e.g. > http://www.gnu.org/software/lightning/manual/html_node/Fibonacci.html which > documents an example similar to llvm/examples/Fibonacci/fibonacci.cpp I > would like the same for LLVM, emitting JIT code, ELF shared library, C > file.... Maybe such a documentation exist (hopefully up to date for > LLVM2.0!) but I did not found it yet! Perhaps just linking the example > source files from the web site could be a good idea... I don't think such a tutorial exists. > > The doxygen documentation is very good, but does not separate enough what an > LLVM user (some developer using LLVM in his own program) should see and what > an LLVM developer (someone enhancing LLVM) should in addition know. Yup. > > I find LLVM great, but quite hard to grasp. There is extensive documentation at http://llvm.org/docs/ Reid. > > Regards. From gdiguardo at gmail.com Wed May 16 07:33:00 2007 From: gdiguardo at gmail.com (Giovanni Di Guardo) Date: Wed, 16 May 2007 14:33:00 +0200 Subject: [LLVMdev] Back End for a stack based architecture Message-ID: <86549f070705160533o788acc2crdf07bd688c5dfa3c@mail.gmail.com> Hi all, I was asked to write a C compiler back end for a dated stack based architecture, i.e. once whose instructions operate only on the top elements of a stack and doesn't use arguments, something like the JVM. I looked at some open source compilers (gcc, sdcc, tinyc and LLVM). To me LLVM seems promising (and I likes C++). Because I'm new here I need your help to understand if: 1) LLVM could be used to target stack based architecture 2) is possible but LLVM is not the best solution for that kind of architecture (in this case any hint for the rigth compiler is very appreciated) thanks, Giovanni From andrewl at lenharth.org Wed May 16 13:04:07 2007 From: andrewl at lenharth.org (Andrew Lenharth) Date: Wed, 16 May 2007 13:04:07 -0500 Subject: [LLVMdev] Back End for a stack based architecture In-Reply-To: <86549f070705160533o788acc2crdf07bd688c5dfa3c@mail.gmail.com> References: <86549f070705160533o788acc2crdf07bd688c5dfa3c@mail.gmail.com> Message-ID: <85dfcd7f0705161104s7fefb768k545328af5ee0982b@mail.gmail.com> On 5/16/07, Giovanni Di Guardo wrote: > 1) LLVM could be used to target stack based architecture There is nothing stopping you from doing so. Probably the common code generation infrastructure won't work for you without extra work. I suspect that you could either write a custom code generator (like the C backend) which doesn't use the common code generation stuff, or you could fake it. By that I mean, model your arch as a register based arch for instruction selection, then do a post pass over it to stackify it instead of running the normal register allocator. Andrew From sabre at nondot.org Wed May 16 14:10:48 2007 From: sabre at nondot.org (Chris Lattner) Date: Wed, 16 May 2007 12:10:48 -0700 (PDT) Subject: [LLVMdev] instruction selector failure In-Reply-To: <464AF5DF.1010608@mail.tuwien.ac.at> References: <464AF5DF.1010608@mail.tuwien.ac.at> Message-ID: On Wed, 16 May 2007, Florian Brandner wrote: > i found a problem in LLVM regarding the matching of 'Constant' nodes in > the instruction selector. the testcase is for x86, but similar testcases > for the other architectures (e.g. ppc) should be easy to create. > > i'm using the llvm-gcc 2.0 prerelease binary package. > > here is the testcase: > int foo(int bar) { > asm("movl %1, %0" : "=r"(bar) : "i"(5)); > return 11; > } > > the problem here is, that the constant node '11' is shared by a > CopyToReg node (for the return) and the INLINEASM node. the INLINEASM > node uses the constant as a flag indicating that an immediate operand (5 > in this case) follows. Yes. this is fixed in mainline, with this series of patches: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070514/049609.html http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070514/049608.html http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070514/049606.html http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070514/049603.html Given the invasiveness of these patches, and the lack of significant testing since the have gone into mainline, I'd recommend against merging them into 2.0. If this blocks a significant piece of software from building with LLVM 2.0 though, we may reconsider. What does it break? -Chris -- http://nondot.org/sabre/ http://llvm.org/ From rafael.espindola at gmail.com Wed May 16 13:41:26 2007 From: rafael.espindola at gmail.com (=?UTF-8?Q?Rafael_Esp=C3=ADndola?=) Date: Wed, 16 May 2007 19:41:26 +0100 Subject: [LLVMdev] (possible) bytecode format change In-Reply-To: <1176965407.13159.103.camel@asl.dorms.spbu.ru> References: <1176940759.13159.94.camel@asl.dorms.spbu.ru> <1176965407.13159.103.camel@asl.dorms.spbu.ru> Message-ID: <564d96fb0705161141i26579d48lad2fe965e8de20ed@mail.gmail.com> > No. Aliases are just "hacks" by its nature. The only reason of > introducing them to LLVM is GCC support. Alias "foo => bar" has meaning > "we're using name foo for calling this function in this module, but > linker well use name bar instead", so this is just quick way to rename > function at module level (e.g. via macros or via some configuration). I > don't see any another reason aliases are useful :) To avoid some PLT lookups: http://people.redhat.com/drepper/dsohowto.pdf Rafael From kenneth.hoste at elis.ugent.be Wed May 16 13:44:41 2007 From: kenneth.hoste at elis.ugent.be (Kenneth Hoste) Date: Wed, 16 May 2007 20:44:41 +0200 Subject: [LLVMdev] FORTRAN compiler status? In-Reply-To: References: <46480559.90608@octopus.com.au> <200705141034.25271.baldrick@free.fr> Message-ID: On 15 May 2007, at 22:15, Michael McCracken wrote: > I just noticed this - I can't promise any particular amount of TLC, > but > I'll certainly be giving the Fortran front-end some attention as > soon as > LLVM moves to gcc 4.2. > > For future reference, does anyone know of a good free Fortran compiler > test suite? I believe the Polyhedron benchmarks (http://www.polyhedron.com/pb05/ polyhedron_benchmark_suite.html) are freely available, but I'm not sure if this qualifies as a test suite. For GCC benchmarks (some of which are Fortran), see http:// www.suse.de/~gcctest/ and off course the GCC testsuite. K. > > Cheers, > -mike > > On 5/14/07, Duncan Sands wrote: >> Hi Duraid, >> >>> Does anyone know what the latest is w.r.t a FORTRAN front-end >>> for >>> LLVM? Is anyone expecting to have typical f90/f95 programs >>> compiling to >>> LLVM this year, or next? (I'm aware of the "NAG hack" and various >>> other >>> f2c-type approaches, but they give me a strange feeling in my >>> tummy.) >> >> support for Fortran will be much easier once LLVM rebases itself on >> gcc 4.2, which I hope will happen within the next few months. >> Then it >> will probably only need a little tender loving care to spring to >> life. >> However, we need a volunteer to provide that love... >> >> Ciao, >> >> Duncan. >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > > > -- > Michael McCracken > UCSD CSE PhD Candidate > research: http://www.cse.ucsd.edu/~mmccrack/ > misc: http://michael-mccracken.net/wp/ > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev -- Computer Science is no more about computers than astronomy is about telescopes. (E. W. Dijkstra) Kenneth Hoste ELIS - Ghent University email: kenneth.hoste at elis.ugent.be blog: http://www.elis.ugent.be/~kehoste/blog website: http://www.elis.ugent.be/~kehoste From tonic at nondot.org Wed May 16 19:24:40 2007 From: tonic at nondot.org (Tanya M. Lattner) Date: Wed, 16 May 2007 17:24:40 -0700 (PDT) Subject: [LLVMdev] Reminder: Review LLVM docs Message-ID: This is just a reminder that we could use some help reviewing the LLVM documentation for the 2.0 release. In particular, the follow documents are some of the most important and should get priority: http://llvm.org/docs/ReleaseNotes.html (MOST IMPORTANT! We need help!) http://llvm.org/docs/GettingStarted.html http://llvm.org/docs/ProgrammersManual.html Please finish all documentation review by Friday, May 18th. Thanks so much! -Tanya From asl at math.spbu.ru Wed May 16 19:14:51 2007 From: asl at math.spbu.ru (Anton Korobeynikov) Date: Thu, 17 May 2007 04:14:51 +0400 Subject: [LLVMdev] Reminder: Review LLVM docs In-Reply-To: References: Message-ID: <1179360891.20870.47.camel@asl.dorms.spbu.ru> Tanya, > Please finish all documentation review by Friday, May 18th. I think "protected visibility" and "hidden visibility and external weak linkage" are things from "one class". It's not good to put them in separate "classes". External weak linkage and hidden visibility, in fact are not llvm-gcc features. They are at LLVM level. -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University. From emil at cs.rmit.edu.au Thu May 17 03:59:24 2007 From: emil at cs.rmit.edu.au (Emil Mikulic) Date: Thu, 17 May 2007 18:59:24 +1000 Subject: [LLVMdev] 2.0-prerelease build errors Message-ID: <20070517085924.GA26262@cs.rmit.edu.au> Hi all, I'm building the LLVM 2.0 pre-release on a brand new FreeBSD 6.2 install. Without the bison package installed, the build breaks: $ tar zxf llvm-2.0.tar.gz $ mkdir objdir $ cd objdir $ ../llvm-2.0/configure $ gmake [...] gmake[2]: Entering directory `/usr/home/emil/objdir/utils/TableGen' llvm[2]: Compiling AsmWriterEmitter.cpp for Release build llvm[2]: Compiling CallingConvEmitter.cpp for Release build llvm[2]: Compiling CodeEmitterGen.cpp for Release build llvm[2]: Compiling CodeGenTarget.cpp for Release build llvm[2]: Compiling DAGISelEmitter.cpp for Release build llvm[2]: Flexing FileLexer.l llvm[2]: Bison of FileParser.y SKIPPED -- bison not found llvm[2]: Compiling FileLexer.cpp for Release build /usr/home/emil/llvm-2.0/utils/TableGen/FileLexer.l:34:24: FileParser.h: No such file or directory Is this a packaging issue where FileParser.h was omitted from the tarball, or does LLVM *need* bison in order to build? If it's the latter case, then should the configure script error out when it can't find bison? e.g. It already errors out quite gracefully if it can't find GNU Make. I see the tarball contains a FileParser.h.cvs but not a FileParser.h -=- With bison installed, the build gets past TableGen but breaks later: gmake[2]: Entering directory `/usr/home/emil/objdir/tools/opt' /usr/home/emil/llvm-2.0/Makefile.rules:1021: *** multiple target patterns. Stop. This is because $(ProjLibsPaths) contains: "/usr/home/emil/objdir/Release/bin/llvm-config llvm-config: Perl not found so llvm-config could not be generated" Should configure also error out if perl isn't installed? -=- With both bison and perl installed, the build succeeds. (phew) --Emil From omiga at ustc.edu Thu May 17 04:11:02 2007 From: omiga at ustc.edu (omiga) Date: Thu, 17 May 2007 17:11:02 +0800 Subject: [LLVMdev] predefined pass for transforming a module to SSA? Message-ID: <200705171711026106342@ustc.edu> Hi all: I'm writing a research prototype on LLVM 1.9. Given a module ,what is the right way to get the SSA-based llvm-IR? As I know , llvmgcc generates SSA-based bytecode. But if a module is constructed by hand, how can I transform it into a SSA-based llvm? Thanks. Ying -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20070517/3f1b0278/attachment.html From asl at math.spbu.ru Thu May 17 05:26:01 2007 From: asl at math.spbu.ru (Anton Korobeynikov) Date: Thu, 17 May 2007 14:26:01 +0400 Subject: [LLVMdev] predefined pass for transforming a module to SSA? In-Reply-To: <200705171711026106342.SS1959SS@ustc.edu> References: <200705171711026106342.SS1959SS@ustc.edu> Message-ID: <1179397561.20870.74.camel@asl.dorms.spbu.ru> Hello, Ying. > But if a module is constructed by hand, how can I transform it into a > SSA-based llvm? LLVM IR is *always* in SSA form, even if you're constructing module by hands (Verifier pass actually does the check and reject invalid code). If you want to eliminate memory accesses and transform them to registers & phi's you might want to run mem2reg pass also. -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University. From criswell at cs.uiuc.edu Thu May 17 08:58:21 2007 From: criswell at cs.uiuc.edu (John Criswell) Date: Thu, 17 May 2007 08:58:21 -0500 Subject: [LLVMdev] predefined pass for transforming a module to SSA? In-Reply-To: <1179397561.20870.74.camel@asl.dorms.spbu.ru> References: <200705171711026106342.SS1959SS@ustc.edu> <1179397561.20870.74.camel@asl.dorms.spbu.ru> Message-ID: <464C5F7D.5050104@cs.uiuc.edu> Anton Korobeynikov wrote: To add to what Anton has said: You need to generate your code in SSA form. Generating SSA code is kind of a pain, so here's the easiest way to do it: 1) Make all of your variables memory locations (LLVM globals or LLVM alloca instructions). Every time you use the variable, use the LLVM load and store instructions to read and write its value. 2) After your LLVM bytecode is generated, use the mem2reg pass (opt -mem2reg) to convert the memory locations into LLVM virtual registers. The mem2reg pass will take care of all the details of creating phi nodes and such. This is what we did for the C frontend in LLVM 1.8 and previous (we probably do it in LLVM 1.9 and later, but I'm not sure). -- John T. > Hello, Ying. > > >> But if a module is constructed by hand, how can I transform it into a >> SSA-based llvm? >> > LLVM IR is *always* in SSA form, even if you're constructing module by > hands (Verifier pass actually does the check and reject invalid code). > If you want to eliminate memory accesses and transform them to registers > & phi's you might want to run mem2reg pass also. > > From evan.cheng at apple.com Thu May 17 13:33:11 2007 From: evan.cheng at apple.com (Evan Cheng) Date: Thu, 17 May 2007 11:33:11 -0700 Subject: [LLVMdev] Back End for a stack based architecture In-Reply-To: <86549f070705160533o788acc2crdf07bd688c5dfa3c@mail.gmail.com> References: <86549f070705160533o788acc2crdf07bd688c5dfa3c@mail.gmail.com> Message-ID: <0DDF23B3-A599-4C81-AE0A-0F4A5022E57C@apple.com> If you want to get something up and running relatively quickly. You can model the backend after X86 X87 FP math. See X86InstrFPStack.td, X86FloatingPoint.cpp Basically add a fake register class and then "stackify" it with a post-allocation pass. Play around with it to see if something like this fits your need. Evan On May 16, 2007, at 5:33 AM, Giovanni Di Guardo wrote: > Hi all, > > I was asked to write a C compiler back end for a dated stack based > architecture, i.e. once whose instructions operate only on the top > elements of a stack and doesn't use arguments, something like the JVM. > > I looked at some open source compilers (gcc, sdcc, tinyc and LLVM). To > me LLVM seems promising (and I likes C++). > > Because I'm new here I need your help to understand if: > > 1) LLVM could be used to target stack based architecture > > 2) is possible but LLVM is not the best solution for that kind of > architecture (in this case any hint for the rigth compiler is very > appreciated) > > thanks, > > Giovanni > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From bram.adams at ugent.be Thu May 17 16:07:28 2007 From: bram.adams at ugent.be (Bram Adams) Date: Thu, 17 May 2007 23:07:28 +0200 Subject: [LLVMdev] Antw.: 2.0 Pre-release tarballs online Message-ID: Hi, Op 15-mei-07, om 10:23 heeft Tanya M. Lattner het volgende geschreven: 1) Download llvm-gcc4 binary and llvm. Compile and run make check. I did a debug build on OSX 10.4.9 and everything went fine. Results of "make check" (see ppc.log): === Summary === # of expected passes 1630 # of unexpected failures 21 # of expected failures 2 3) Compile llvm-gcc4 and llvm from source. Run 'make check'. On Slackware 10.2 (GCC 3.3.6), I got an error during a debug build with the header files using uintptr_t (not recognised as a type). Putting "#include " in include/llvm/BasicBlock.h (llvm) and in "include/llvm/ValueSymbolTable.h" (frontend) resolved this. Also, I got linking errors while linking tblgen (see error.txt). Any ideas about this? Results of "make check" (without tblgen; see x86.log): === Summary === # of expected passes 1423 # of unexpected failures 25 # of expected failures 3 It would also be helpful for someone to compile/test with objdir != srcdir. Both builds above happened in a directory separate from the source directory. About LTO support: the new release documents don't mention anything about this. Also, the relevant bugzilla entries I could find date back to March 2007. Has any progress been made recently in adding LTO to the Darwin linker and/or GNU binutils? About porting from 1.9 to 2.0: it would be helpful to have some kind of porting guide as I encountered a lot of API changes, e.g.: * SymbolTable.h has vanished * Type::IntTy, Type::UIntTy, Type::SByteTy, ... are replaced by Type::Int8Ty, ... How does one keep code portable with the various TypeIntXTy's? * GetElementPtrInst's constructor doesn't accept an std::vector anymore but requires explicit arguments. * CastInst is now abstract and its functionality is split into several parts. What to choose when casting a pointer to a double pointer? Is it always clear which cast instruction is the right one (e.g. when exact Value is only known at run-time)? * Instruction::getNext()/Prev() have suddenly become private, seemingly without fast, easy to use alternative. Is iterating through the parent BasicBlock's iterator the only solution? * The same goes for BasicBlock::getNext()/Prev(). Is iterating through the parent Function's iterator the only solution? * CallInst's constructors do not accept vectors anymore, but a double pointer (!) instead. Why? * Module::getNamedFunction() is now called Module::getFunction(). * llvm/Transforms/Utils/Cloning.h's CloneFunctionInto() needs a DenseMap as its third argument instead of an STL map. * Pass's constructor now needs an intptr_t as explained in the updated "Write your first pass"-document. * In my own code, I can't use cout anymore without the std:: prefix. * ConstantBool/Integral/Int are merged into ConstantInt. * %llvm.dbg.subprogram.type's line number is now the 7th element; its compile unit is now the 6th element. * Argument names have got their argument index appended to their name in the LLVM bitcode (e.g. "define void @f(i32 %Arg1, i32 % OtherArg2) {...}" instead of "define void @f(i32 %Arg, i32 %OtherArg) {...}"). * ... (there is probably more, as my app compiles by now, but is still broken) Kind regards, Bram Adams GH-SEL, INTEC, Ghent University (Belgium) ? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20070517/384cf38a/attachment-0002.html -------------- next part -------------- A non-text attachment was scrubbed... Name: logs.zip Type: application/zip Size: 40502 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20070517/384cf38a/attachment-0001.zip -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20070517/384cf38a/attachment-0003.html From sabre at nondot.org Thu May 17 17:11:37 2007 From: sabre at nondot.org (Chris Lattner) Date: Thu, 17 May 2007 15:11:37 -0700 (PDT) Subject: [LLVMdev] API changes (was Antw.: 2.0 Pre-release tarballs online) In-Reply-To: References: Message-ID: On Thu, 17 May 2007, Bram Adams wrote: > About LTO support: the new release documents don't mention anything about > this. Also, the relevant bugzilla entries I could find date back to March > 2007. Has any progress been made recently in adding LTO to the Darwin linker > and/or GNU binutils? I'll mention this in the release notes. The darwin linker in 10.5 (not yet released) supports llvm, and there is an experimental patch for binutils, but I don't knows its current state. > About porting from 1.9 to 2.0: it would be helpful to have some kind of > porting guide as I encountered a lot of API changes, e.g.: This is all great information, I'm merging this into the release notes. > * Type::IntTy, Type::UIntTy, Type::SByteTy, ... are replaced by > Type::Int8Ty, ... How does one keep code portable with the various > TypeIntXTy's? LLVM integer types have always been fixed size. "long" didn't correspond to C's "long" type, it was always 64-bits. > * CastInst is now abstract and its functionality is split into several > parts. What to choose when casting a pointer to a double pointer? pointer to pointer casts are always bitcast. > Is it > always clear which cast instruction is the right one (e.g. when exact Value > is only known at run-time)? Yep. :) > * Instruction::getNext()/Prev() have suddenly become private, seemingly > without fast, easy to use alternative. Is iterating through the parent > BasicBlock's iterator the only solution? Yes. The next/prev pointers have extra information encoded in them now, for efficiency. The iterator takes care of this for you, deferencing the raw pointer wouldn't work even if you could get to it. > * The same goes for BasicBlock::getNext()/Prev(). Is iterating through the > parent Function's iterator the only solution? Yep. > * CallInst's constructors do not accept vectors anymore, but a double > pointer (!) instead. Why? Most calls have been changed to take a range instead of a vector instead. This allows you to do things like this: Value *Ops[] = { Op1, Op2, Op3 }; new Whatever(Ops, 3); which avoids creating a temporary vector. > * In my own code, I can't use cout anymore without the std:: prefix. You should have always used std:: :) > * ... (there is probably more, as my app compiles by now, but is still > broken) This is all very useful. If you have any more additions, please let me know. Thanks again, -Chris -- http://nondot.org/sabre/ http://llvm.org/ From tonic at nondot.org Thu May 17 17:15:09 2007 From: tonic at nondot.org (Tanya M. Lattner) Date: Thu, 17 May 2007 15:15:09 -0700 (PDT) Subject: [LLVMdev] 2.0-prerelease build errors In-Reply-To: <20070517085924.GA26262@cs.rmit.edu.au> References: <20070517085924.GA26262@cs.rmit.edu.au> Message-ID: > llvm[2]: Flexing FileLexer.l > llvm[2]: Bison of FileParser.y SKIPPED -- bison not found > llvm[2]: Compiling FileLexer.cpp for Release build > /usr/home/emil/llvm-2.0/utils/TableGen/FileLexer.l:34:24: FileParser.h: No such file or directory > > Is this a packaging issue where FileParser.h was omitted > from the tarball, or does LLVM *need* bison in order to build? No, bison should not be required. You have found a bug in our Makefiles. > With bison installed, the build gets past TableGen but breaks later: > gmake[2]: Entering directory `/usr/home/emil/objdir/tools/opt' > /usr/home/emil/llvm-2.0/Makefile.rules:1021: *** multiple target patterns. Stop. > > This is because $(ProjLibsPaths) contains: > "/usr/home/emil/objdir/Release/bin/llvm-config llvm-config: Perl not > found so llvm-config could not be generated" > > Should configure also error out if perl isn't installed? Yes. Reid has changed this so that perl is now required. Thanks so much for reporting these! -Tanya From rspencer at reidspencer.com Thu May 17 16:38:14 2007 From: rspencer at reidspencer.com (Reid Spencer) Date: Thu, 17 May 2007 21:38:14 +0000 Subject: [LLVMdev] Antw.: 2.0 Pre-release tarballs online In-Reply-To: References: Message-ID: <1179437894.1233.605.camel@bashful.x10sys.com> On Thu, 2007-05-17 at 23:07 +0200, Bram Adams wrote: > Hi, > > > Op 15-mei-07, om 10:23 heeft Tanya M. Lattner het volgende geschreven: > 1) Download llvm-gcc4 binary and llvm. Compile and run make check. > > > I did a debug build on OSX 10.4.9 and everything went fine. Good. > > > Results of "make check" (see ppc.log): > > > === Summary === > > > # of expected passes 1630 > # of unexpected failures 21 > # of expected failures 2 This doesn't look like there's enough tests. The total number should be in the high 1900s. Did you configure with only the PPC target? > > 3) Compile llvm-gcc4 and llvm from source. Run 'make check'. > > > On Slackware 10.2 (GCC 3.3.6), I got an error during a debug build > with the header files using uintptr_t (not recognised as a type). > Putting "#include " in include/llvm/BasicBlock.h (llvm) and > in "include/llvm/ValueSymbolTable.h" (frontend) resolved this. This isn't the correct solution :) We don't (or try not) to include system headers anywhere except lib/System and a few spots in include/llvm/Support. The case in point is include/llvm/Support/DataTypes.h. Please adjust include/llvm/Support/DataTypes.h to accommodate this operating system and send the patch to llvm-commits mailing list. We'll include it so that LLVM can compile on Slackware 10.2 with gcc 3.3.6. ... snip ... Others have responded to the rest. Reid. > From angray at beeb.net Thu May 17 16:54:56 2007 From: angray at beeb.net (Aaron Gray) Date: Thu, 17 May 2007 22:54:56 +0100 Subject: [LLVMdev] 2.0 Pre-release tarballs online References: Message-ID: <1b7701c798ce$02834230$0200a8c0@AMD2500> Tanya, I have done make check and nightly report tests on LLVM on the GCC 4.2.0 release, on Linux x86 32 bit. On make check the bit intrinsics test is still failing but it works from the command line, strange ? What files do you want from the nightly report, as I am not familiar with it ? I will be doing Cygwin tests next. Aaron ----- Original Message ----- From: "Tanya M. Lattner" To: "LLVM Developers Mailing List" Sent: Tuesday, May 15, 2007 9:23 AM Subject: [LLVMdev] 2.0 Pre-release tarballs online > > I've uploaded the 2.0 pre-release to this location: > http://llvm.org/prereleases/2.0/ > > If you have free time and would like to help test this release, please > download the appropriate tarballs from the website. > > Here are a few ways you can help test this release: > > 1) Download llvm-gcc4 binary and llvm. Compile and run make check. > > 2) Download llvm-gcc4 binary, llvm, and llvm-test. Compile, run make > check, and do "make ENABLE_OPTIMIZED=1 TEST=nightly report" in llvm-test. > > 3) Compile llvm-gcc4 and llvm from source. Run 'make check'. > > 4) Compile llvm-gcc4 and llvm from source. Run 'make check' and do a 'make > ENABLE_OPTIMIZED=1 TEST=nightly report' in llvm-test. > > It would also be helpful for someone to compile/test with objdir != > srcdir. > The 2.0 release defaults to a Release build, but you are welcome > to test with a Debug build as well. > > When reporting your results, please email the list and mention what > platform, which option you chose (1, 2, 3, or 4), and if you made any > configure changes (objdir != srcdir, or Debug build). Include the dejagnu > test log or the nightly test report. > > Thanks, > Tanya Lattner > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.467 / Virus Database: 269.7.1/805 - Release Date: 15/05/2007 > 10:47 > From rspencer at reidspencer.com Thu May 17 17:12:38 2007 From: rspencer at reidspencer.com (Reid Spencer) Date: Thu, 17 May 2007 22:12:38 +0000 Subject: [LLVMdev] 2.0 Pre-release tarballs online In-Reply-To: <1b7701c798ce$02834230$0200a8c0@AMD2500> References: <1b7701c798ce$02834230$0200a8c0@AMD2500> Message-ID: <1179439958.1233.609.camel@bashful.x10sys.com> Aaron, On Thu, 2007-05-17 at 22:54 +0100, Aaron Gray wrote: > Tanya, > > I have done make check and nightly report tests on LLVM on the GCC 4.2.0 > release, on Linux x86 32 bit. > > On make check the bit intrinsics test is still failing but it works from the > command line, strange ? Can you be a bit more specific about which test is failing? Reid. > > What files do you want from the nightly report, as I am not familiar with it > ? > > I will be doing Cygwin tests next. > > Aaron > > ----- Original Message ----- > From: "Tanya M. Lattner" > To: "LLVM Developers Mailing List" > Sent: Tuesday, May 15, 2007 9:23 AM > Subject: [LLVMdev] 2.0 Pre-release tarballs online > > > > > > I've uploaded the 2.0 pre-release to this location: > > http://llvm.org/prereleases/2.0/ > > > > If you have free time and would like to help test this release, please > > download the appropriate tarballs from the website. > > > > Here are a few ways you can help test this release: > > > > 1) Download llvm-gcc4 binary and llvm. Compile and run make check. > > > > 2) Download llvm-gcc4 binary, llvm, and llvm-test. Compile, run make > > check, and do "make ENABLE_OPTIMIZED=1 TEST=nightly report" in llvm-test. > > > > 3) Compile llvm-gcc4 and llvm from source. Run 'make check'. > > > > 4) Compile llvm-gcc4 and llvm from source. Run 'make check' and do a 'make > > ENABLE_OPTIMIZED=1 TEST=nightly report' in llvm-test. > > > > It would also be helpful for someone to compile/test with objdir != > > srcdir. > > The 2.0 release defaults to a Release build, but you are welcome > > to test with a Debug build as well. > > > > When reporting your results, please email the list and mention what > > platform, which option you chose (1, 2, 3, or 4), and if you made any > > configure changes (objdir != srcdir, or Debug build). Include the dejagnu > > test log or the nightly test report. > > > > Thanks, > > Tanya Lattner > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > > > -- > > No virus found in this incoming message. > > Checked by AVG Free Edition. > > Version: 7.5.467 / Virus Database: 269.7.1/805 - Release Date: 15/05/2007 > > 10:47 > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From asl at math.spbu.ru Thu May 17 17:12:25 2007 From: asl at math.spbu.ru (Anton Korobeynikov) Date: Fri, 18 May 2007 02:12:25 +0400 Subject: [LLVMdev] Antw.: 2.0 Pre-release tarballs online In-Reply-To: <1179437894.1233.605.camel.SS1633SS@bashful.x10sys.com> References: <1179437894.1233.605.camel.SS1633SS@bashful.x10sys.com> Message-ID: <1179439945.20870.95.camel@asl.dorms.spbu.ru> Hello, Reid. > This doesn't look like there's enough tests. The total number should > be > in the high 1900s. Did you configure with only the PPC target? Yes. I've looked into logs. All "unexpected" are either due to lack of targets (ppc only) or no llvm-gcc found. -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University. From rspencer at reidspencer.com Thu May 17 17:52:31 2007 From: rspencer at reidspencer.com (Reid Spencer) Date: Thu, 17 May 2007 22:52:31 +0000 Subject: [LLVMdev] 2.0-prerelease build errors In-Reply-To: References: <20070517085924.GA26262@cs.rmit.edu.au> Message-ID: <1179442351.1233.614.camel@bashful.x10sys.com> On Thu, 2007-05-17 at 15:15 -0700, Tanya M. Lattner wrote: > > llvm[2]: Flexing FileLexer.l > > llvm[2]: Bison of FileParser.y SKIPPED -- bison not found > > llvm[2]: Compiling FileLexer.cpp for Release build > > /usr/home/emil/llvm-2.0/utils/TableGen/FileLexer.l:34:24: FileParser.h: No such file or directory > > > > Is this a packaging issue where FileParser.h was omitted > > from the tarball, or does LLVM *need* bison in order to build? > > No, bison should not be required. You have found a bug in our Makefiles. That bug has now been fixed on the release_20 branch and on mainline. Its only been tested on Linux. I would appreciate some verification on other hosts. Thanks, Reid. > > > With bison installed, the build gets past TableGen but breaks later: > > gmake[2]: Entering directory `/usr/home/emil/objdir/tools/opt' > > /usr/home/emil/llvm-2.0/Makefile.rules:1021: *** multiple target patterns. Stop. > > > > This is because $(ProjLibsPaths) contains: > > "/usr/home/emil/objdir/Release/bin/llvm-config llvm-config: Perl not > > found so llvm-config could not be generated" > > > > Should configure also error out if perl isn't installed? > > Yes. Reid has changed this so that perl is now required. > > Thanks so much for reporting these! > > -Tanya > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From tonic at nondot.org Thu May 17 18:47:59 2007 From: tonic at nondot.org (Tanya M. Lattner) Date: Thu, 17 May 2007 16:47:59 -0700 (PDT) Subject: [LLVMdev] Antw.: 2.0 Pre-release tarballs online In-Reply-To: References: Message-ID: > 3) Compile llvm-gcc4 and llvm from source. Run 'make check'. > > On Slackware 10.2 (GCC 3.3.6), I got an error during a debug build with > the header files using uintptr_t (not recognised as a type). Putting > "#include " in include/llvm/BasicBlock.h (llvm) and in > "include/llvm/ValueSymbolTable.h" (frontend) resolved this. > > Also, I got linking errors while linking tblgen (see error.txt). Any ideas > about this? I'll look into these two in a bit. Thanks! > Results of "make check" (without tblgen; see x86.log): > > === Summary === > # of expected passes 1423 > # of unexpected failures 25 > # of expected failures 3 Can you verify that you have llvm-gcc in your path and that its the 2.0 llvm-gcc? The errors are mostly saying the tests couldnt find llvm-gcc and also the path looked like a 1.9 one. Thanks, Tanya > > It would also be helpful for someone to compile/test with objdir != > srcdir. > > Both builds above happened in a directory separate from the source > directory. > > About LTO support: the new release documents don't mention anything about > this. Also, the relevant bugzilla entries I could find date back to March > 2007. Has any progress been made recently in adding LTO to the Darwin > linker and/or GNU binutils? > > About porting from 1.9 to 2.0: it would be helpful to have some kind of > porting guide as I encountered a lot of API changes, e.g.: > * SymbolTable.h has vanished > * Type::IntTy, Type::UIntTy, Type::SByteTy, ... are replaced by > Type::Int8Ty, ... How does one keep code portable with the various > TypeIntXTy's? > * GetElementPtrInst's constructor doesn't accept an std::vector anymore > but requires explicit arguments. > * CastInst is now abstract and its functionality is split into several > parts. What to choose when casting a pointer to a double pointer? Is it > always clear which cast instruction is the right one (e.g. when exact > Value is only known at run-time)? > * Instruction::getNext()/Prev() have suddenly become private, seemingly > without fast, easy to use alternative. Is iterating through the parent > BasicBlock's iterator the only solution? > * The same goes for BasicBlock::getNext()/Prev(). Is iterating through > the parent Function's iterator the only solution? > * CallInst's constructors do not accept vectors anymore, but a double > pointer (!) instead. Why? > * Module::getNamedFunction() is now called Module::getFunction(). > * llvm/Transforms/Utils/Cloning.h's CloneFunctionInto() needs a > DenseMap as its third argument instead of an STL map. > * Pass's constructor now needs an intptr_t as explained in the updated > "Write your first pass"-document. > * In my own code, I can't use cout anymore without the std:: prefix. > * ConstantBool/Integral/Int are merged into ConstantInt. > * %llvm.dbg.subprogram.type's line number is now the 7th element; > its compile unit is now the 6th element. > * Argument names have got their argument index appended to their name in > the LLVM bitcode (e.g. "define void @f(i32 %Arg1, i32 %OtherArg2) {...}" > instead of "define void @f(i32 %Arg, i32 %OtherArg) {...}"). > * ... (there is probably more, as my app compiles by now, but is still > broken) > > Kind regards, > > Bram Adams > GH-SEL, INTEC, Ghent University (Belgium) > ??? > From angray at beeb.net Thu May 17 18:01:06 2007 From: angray at beeb.net (Aaron Gray) Date: Fri, 18 May 2007 00:01:06 +0100 Subject: [LLVMdev] 2.0 Pre-release tarballs online References: <1b7701c798ce$02834230$0200a8c0@AMD2500> <1179439958.1233.609.camel@bashful.x10sys.com> Message-ID: <1bc401c798d7$410118d0$0200a8c0@AMD2500> > Aaron, > > On Thu, 2007-05-17 at 22:54 +0100, Aaron Gray wrote: >> Tanya, >> >> I have done make check and nightly report tests on LLVM on the GCC 4.2.0 >> release, on Linux x86 32 bit. >> >> On make check the bit intrinsics test is still failing but it works from >> the >> command line, strange ? > > Can you be a bit more specific about which test is failing? > Running /usr/src/llvm/test/CodeGen/Generic/dg.exp ... FAIL: /usr/src/llvm/test/CodeGen/Generic/bit-intrinsics.ll Failed with signal(SIGSEGV) at line 2 while running: lli --force-interpreter=true Output/bit-intrinsics.ll.tmp.bc lli[0x84717fc] Chris looked at this and we found the test works fine when done separately from the command line. Aaron >> ----- Original Message ----- >> From: "Tanya M. Lattner" >> To: "LLVM Developers Mailing List" >> Sent: Tuesday, May 15, 2007 9:23 AM >> Subject: [LLVMdev] 2.0 Pre-release tarballs online >> >> >> > >> > I've uploaded the 2.0 pre-release to this location: >> > http://llvm.org/prereleases/2.0/ >> > >> > If you have free time and would like to help test this release, please >> > download the appropriate tarballs from the website. >> > >> > Here are a few ways you can help test this release: >> > >> > 1) Download llvm-gcc4 binary and llvm. Compile and run make check. >> > >> > 2) Download llvm-gcc4 binary, llvm, and llvm-test. Compile, run make >> > check, and do "make ENABLE_OPTIMIZED=1 TEST=nightly report" in >> > llvm-test. >> > >> > 3) Compile llvm-gcc4 and llvm from source. Run 'make check'. >> > >> > 4) Compile llvm-gcc4 and llvm from source. Run 'make check' and do a >> > 'make >> > ENABLE_OPTIMIZED=1 TEST=nightly report' in llvm-test. >> > >> > It would also be helpful for someone to compile/test with objdir != >> > srcdir. >> > The 2.0 release defaults to a Release build, but you are welcome >> > to test with a Debug build as well. >> > >> > When reporting your results, please email the list and mention what >> > platform, which option you chose (1, 2, 3, or 4), and if you made any >> > configure changes (objdir != srcdir, or Debug build). Include the >> > dejagnu >> > test log or the nightly test report. >> > >> > Thanks, >> > Tanya Lattner >> > _______________________________________________ >> > LLVM Developers mailing list >> > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > >> > >> > -- >> > No virus found in this incoming message. >> > Checked by AVG Free Edition. >> > Version: 7.5.467 / Virus Database: 269.7.1/805 - Release Date: >> > 15/05/2007 >> > 10:47 >> > >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.467 / Virus Database: 269.7.1/807 - Release Date: 16/05/2007 > 18:05 > From emil at cs.rmit.edu.au Thu May 17 21:19:02 2007 From: emil at cs.rmit.edu.au (Emil Mikulic) Date: Fri, 18 May 2007 12:19:02 +1000 Subject: [LLVMdev] 2.0-prerelease build errors In-Reply-To: References: <20070517085924.GA26262@cs.rmit.edu.au> Message-ID: <20070518021902.GB12692@cs.rmit.edu.au> On Thu, May 17, 2007 at 03:15:09PM -0700, Tanya M. Lattner wrote: > > Should configure also error out if perl isn't installed? > > Yes. Reid has changed this so that perl is now required. > > Thanks so much for reporting these! You're welcome! I'm still working on the "method four" testing that you requested. The "make check" is done, results are here: http://goanna.cs.rmit.edu.au/~emil/llvm-2.0-make-check.txt Summary: Native configuration is i386-unknown-freebsd6.2 # of expected passes 1988 # of expected failures 3 -=- I'm currently stuck on the nightly report, at this point: /usr/home/emil/llvm-test/RunSafely.sh 500 0 /dev/null Output/tramp3d-v4.out-nat Output/tramp3d-v4.native --cartvis 1.0 0.0 --rhomin 1e-8 -n 25 Ctrl-T tells me that tramp3d-v4.native has by now consumed 50,000 seconds of CPU time. Somehow I don't think it's going to stop anytime soon -- what can I do to break out of this cleanly and get the whole report built? -=- Other than that, llvm and llvm-gcc seem to build and work quite nicely on FreeBSD 6.2-RELEASE. I'm hoping to eventually get a FreeBSD port for llvm-gcc added, after LLVM 2.0 is officially released. --Emil From rspencer at reidspencer.com Thu May 17 21:30:50 2007 From: rspencer at reidspencer.com (Reid Spencer) Date: Fri, 18 May 2007 02:30:50 +0000 Subject: [LLVMdev] 2.0-prerelease build errors In-Reply-To: <20070518021902.GB12692@cs.rmit.edu.au> References: <20070517085924.GA26262@cs.rmit.edu.au> <20070518021902.GB12692@cs.rmit.edu.au> Message-ID: <1179455450.1233.643.camel@bashful.x10sys.com> On Fri, 2007-05-18 at 12:19 +1000, Emil Mikulic wrote: > On Thu, May 17, 2007 at 03:15:09PM -0700, Tanya M. Lattner wrote: > > > Should configure also error out if perl isn't installed? > > > > Yes. Reid has changed this so that perl is now required. > > > > Thanks so much for reporting these! > > You're welcome! > > I'm still working on the "method four" testing that you requested. > > The "make check" is done, results are here: > http://goanna.cs.rmit.edu.au/~emil/llvm-2.0-make-check.txt Looks perfect to me. > > Summary: > Native configuration is i386-unknown-freebsd6.2 > # of expected passes 1988 > # of expected failures 3 > > -=- > > I'm currently stuck on the nightly report, at this point: > /usr/home/emil/llvm-test/RunSafely.sh 500 0 /dev/null Output/tramp3d-v4.out-nat Output/tramp3d-v4.native --cartvis 1.0 0.0 --rhomin 1e-8 -n 25 > > Ctrl-T tells me that tramp3d-v4.native has by now consumed 50,000 > seconds of CPU time. Somehow I don't think it's going to stop anytime > soon -- what can I do to break out of this cleanly and get the whole > report built? The "500" on that command line is supposed to stop it after 500 seconds of CPU time. 50,000 is WAY too much. You should just kill the "tramp3d-v4.native" process and it will carry on from there. BTW, Obviously RunSafely.sh is not working well on freebsd. Could you do me a favor? I could fix this if I had: 1. the output of "uname -s" on your system 2. A description of the ulimit (man page?) command for your shell/system. Specifically, is the -t option supported to limit cpu time and what are the units? > > -=- > > Other than that, llvm and llvm-gcc seem to build and work quite nicely > on FreeBSD 6.2-RELEASE. I'm hoping to eventually get a FreeBSD port for > llvm-gcc added, after LLVM 2.0 is officially released. Very nice, that would be much appreciated and would make some of our FreeBSD users happy :) Best Regards, Reid. > > --Emil > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From emil at cs.rmit.edu.au Thu May 17 22:11:57 2007 From: emil at cs.rmit.edu.au (Emil Mikulic) Date: Fri, 18 May 2007 13:11:57 +1000 Subject: [LLVMdev] 2.0 Pre-release tarballs online In-Reply-To: References: Message-ID: <20070518031157.GA23323@cs.rmit.edu.au> On Tue, May 15, 2007 at 01:23:32AM -0700, Tanya M. Lattner wrote: > 4) Compile llvm-gcc4 and llvm from source. Run 'make check' and do a 'make > ENABLE_OPTIMIZED=1 TEST=nightly report' in llvm-test. > > It would also be helpful for someone to compile/test with objdir != srcdir. This is on FreeBSD 6.2-RELEASE, on i386. Both llvm and llvm-gcc were compiled with objdir != srcdir. Release, not Debug build of LLVM. http://goanna.cs.rmit.edu.au/~emil/llvm-2.0-make-check.txt http://goanna.cs.rmit.edu.au/~emil/llvm-2.0-report.nightly.txt --Emil From tonic at nondot.org Fri May 18 00:11:51 2007 From: tonic at nondot.org (Tanya M. Lattner) Date: Thu, 17 May 2007 22:11:51 -0700 (PDT) Subject: [LLVMdev] 2.0 Pre-release tarballs online In-Reply-To: <20070518031157.GA23323@cs.rmit.edu.au> References: <20070518031157.GA23323@cs.rmit.edu.au> Message-ID: > On Tue, May 15, 2007 at 01:23:32AM -0700, Tanya M. Lattner wrote: >> 4) Compile llvm-gcc4 and llvm from source. Run 'make check' and do a 'make >> ENABLE_OPTIMIZED=1 TEST=nightly report' in llvm-test. >> >> It would also be helpful for someone to compile/test with objdir != srcdir. > > This is on FreeBSD 6.2-RELEASE, on i386. > Both llvm and llvm-gcc were compiled with objdir != srcdir. > Release, not Debug build of LLVM. > > http://goanna.cs.rmit.edu.au/~emil/llvm-2.0-make-check.txt > http://goanna.cs.rmit.edu.au/~emil/llvm-2.0-report.nightly.txt Thank you so much for testing the release!! I've checked out the nightly test report and it looks like there is potentially one regression. SingleSource/UnitTests/Vector/SSE/sse.expandfft However, I need you to look at your /proc/cpuinfo (or whatever it is on FreeBSD) to tell me what flavors of sse you have (mmx, sse1, sse2, etc). Thanks, Tanya > > --Emil > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From emil at cs.rmit.edu.au Fri May 18 00:57:06 2007 From: emil at cs.rmit.edu.au (Emil Mikulic) Date: Fri, 18 May 2007 15:57:06 +1000 Subject: [LLVMdev] 2.0 Pre-release tarballs online In-Reply-To: References: <20070518031157.GA23323@cs.rmit.edu.au> Message-ID: <20070518055706.GA6875@cs.rmit.edu.au> On Thu, May 17, 2007 at 10:11:51PM -0700, Tanya M. Lattner wrote: > > On Tue, May 15, 2007 at 01:23:32AM -0700, Tanya M. Lattner wrote: > >> 4) Compile llvm-gcc4 and llvm from source. Run 'make check' and do a 'make > >> ENABLE_OPTIMIZED=1 TEST=nightly report' in llvm-test. > >> > >> It would also be helpful for someone to compile/test with objdir != srcdir. > > > > This is on FreeBSD 6.2-RELEASE, on i386. > > Both llvm and llvm-gcc were compiled with objdir != srcdir. > > Release, not Debug build of LLVM. > > > > http://goanna.cs.rmit.edu.au/~emil/llvm-2.0-make-check.txt > > http://goanna.cs.rmit.edu.au/~emil/llvm-2.0-report.nightly.txt > > Thank you so much for testing the release!! You're welcome! > I've checked out the nightly test report and it looks like there is > potentially one regression. > SingleSource/UnitTests/Vector/SSE/sse.expandfft > > However, I need you to look at your /proc/cpuinfo (or whatever it is > on FreeBSD) to tell me what flavors of sse you have (mmx, sse1, sse2, > etc). dmesg says: CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (3000.12-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf34 Stepping = 4 Features=0xbfebfbff Features2=0x441d> Looks like 1, 2, _and_ 3 are supported. is xTPR (Send Task Priority Messages) --Emil From sabre at nondot.org Fri May 18 01:55:37 2007 From: sabre at nondot.org (Chris Lattner) Date: Thu, 17 May 2007 23:55:37 -0700 (PDT) Subject: [LLVMdev] 2.0 Pre-release tarballs online In-Reply-To: <20070518055706.GA6875@cs.rmit.edu.au> References: <20070518031157.GA23323@cs.rmit.edu.au> <20070518055706.GA6875@cs.rmit.edu.au> Message-ID: On Fri, 18 May 2007, Emil Mikulic wrote: > > CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (3000.12-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0xf34 Stepping = 4 > Features=0xbfebfbff MOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> > Features2=0x441d> > > Looks like 1, 2, _and_ 3 are supported. > is xTPR (Send Task Priority Messages) Okay, this is probably some stack alignment issue or something. Can you please file a bug? This is not a 2.0 blocker, but we want to track it. Thanks! -Chris -- http://nondot.org/sabre/ http://llvm.org/ From sabre at nondot.org Fri May 18 02:37:55 2007 From: sabre at nondot.org (Chris Lattner) Date: Fri, 18 May 2007 00:37:55 -0700 (PDT) Subject: [LLVMdev] Release notes draft done Message-ID: Hi All, The first draft of the release notes are now done (many thanks to Tanya for pulling together info from the announcements): http://llvm.org/docs/ReleaseNotes.html If you have comments/feedback, please let me know, or - better yet - just commit improvements to mainline :) -Chris -- http://nondot.org/sabre/ http://llvm.org/ From manishagg22 at gmail.com Fri May 18 01:54:54 2007 From: manishagg22 at gmail.com (manish) Date: Fri, 18 May 2007 12:24:54 +0530 Subject: [LLVMdev] how to dump data stuctures of llvm in llvm-gcc Message-ID: <31ba424e0705172354m25d61d88sc1c283cdba02bcdc@mail.gmail.com> Hi All, Can any one please tell me the option in llvm-gcc to dump data structures of llvm and llvm IR. Thanks and regards, Manish From tonic at nondot.org Fri May 18 02:59:08 2007 From: tonic at nondot.org (Tanya M. Lattner) Date: Fri, 18 May 2007 00:59:08 -0700 (PDT) Subject: [LLVMdev] 2.0 Pre-release tarballs online In-Reply-To: <1b7701c798ce$02834230$0200a8c0@AMD2500> References: <1b7701c798ce$02834230$0200a8c0@AMD2500> Message-ID: > On make check the bit intrinsics test is still failing but it works from the > command line, strange ? Did Chris help you with this or is it still an issue? > What files do you want from the nightly report, as I am not familiar with it > ? in llvm-test, if you run the gmake TEST=nightly report command it will generated a report.nightly.txt file. Thats what I want to see. Thanks! -Tanya > > I will be doing Cygwin tests next. > > Aaron > > ----- Original Message ----- > From: "Tanya M. Lattner" > To: "LLVM Developers Mailing List" > Sent: Tuesday, May 15, 2007 9:23 AM > Subject: [LLVMdev] 2.0 Pre-release tarballs online > > >> >> I've uploaded the 2.0 pre-release to this location: >> http://llvm.org/prereleases/2.0/ >> >> If you have free time and would like to help test this release, please >> download the appropriate tarballs from the website. >> >> Here are a few ways you can help test this release: >> >> 1) Download llvm-gcc4 binary and llvm. Compile and run make check. >> >> 2) Download llvm-gcc4 binary, llvm, and llvm-test. Compile, run make >> check, and do "make ENABLE_OPTIMIZED=1 TEST=nightly report" in llvm-test. >> >> 3) Compile llvm-gcc4 and llvm from source. Run 'make check'. >> >> 4) Compile llvm-gcc4 and llvm from source. Run 'make check' and do a 'make >> ENABLE_OPTIMIZED=1 TEST=nightly report' in llvm-test. >> >> It would also be helpful for someone to compile/test with objdir != >> srcdir. >> The 2.0 release defaults to a Release build, but you are welcome >> to test with a Debug build as well. >> >> When reporting your results, please email the list and mention what >> platform, which option you chose (1, 2, 3, or 4), and if you made any >> configure changes (objdir != srcdir, or Debug build). Include the dejagnu >> test log or the nightly test report. >> >> Thanks, >> Tanya Lattner >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> >> -- >> No virus found in this incoming message. >> Checked by AVG Free Edition. >> Version: 7.5.467 / Virus Database: 269.7.1/805 - Release Date: 15/05/2007 >> 10:47 >> > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From tonic at nondot.org Fri May 18 03:10:11 2007 From: tonic at nondot.org (Tanya M. Lattner) Date: Fri, 18 May 2007 01:10:11 -0700 (PDT) Subject: [LLVMdev] Antw.: 2.0 Pre-release tarballs online In-Reply-To: References: Message-ID: > On Slackware 10.2 (GCC 3.3.6), I got an error during a debug build with the > header files using uintptr_t (not recognised as a type). Putting "#include > " in include/llvm/BasicBlock.h (llvm) and in > "include/llvm/ValueSymbolTable.h" (frontend) resolved this. Ok. This is now fixed on the release branch. Thanks! > Also, I got linking errors while linking tblgen (see error.txt). Any ideas > about this? I'm not really sure whats going on here and I can't reproduce this since I don't have your setup. Its probably either an issue with gcc or ld (try upgrading to 2.17.X if possible). If you can try to investigate it further, that would be great. Then file a bug for it. Otherwise, I think the make check errors are ok given it can't find llvm-gcc. Thanks! -Tanya > > Results of "make check" (without tblgen; see x86.log): > > === Summary === > # of expected passes 1423 > # of unexpected failures 25 > # of expected failures 3 > > It would also be helpful for someone to compile/test with objdir != srcdir. > > Both builds above happened in a directory separate from the source directory. > > About LTO support: the new release documents don't mention anything about > this. Also, the relevant bugzilla entries I could find date back to March > 2007. Has any progress been made recently in adding LTO to the Darwin linker > and/or GNU binutils? > > About porting from 1.9 to 2.0: it would be helpful to have some kind of > porting guide as I encountered a lot of API changes, e.g.: > * SymbolTable.h has vanished > * Type::IntTy, Type::UIntTy, Type::SByteTy, ... are replaced by > Type::Int8Ty, ... How does one keep code portable with the various > TypeIntXTy's? > * GetElementPtrInst's constructor doesn't accept an std::vector anymore but > requires explicit arguments. > * CastInst is now abstract and its functionality is split into several > parts. What to choose when casting a pointer to a double pointer? Is it > always clear which cast instruction is the right one (e.g. when exact Value > is only known at run-time)? > * Instruction::getNext()/Prev() have suddenly become private, seemingly > without fast, easy to use alternative. Is iterating through the parent > BasicBlock's iterator the only solution? > * The same goes for BasicBlock::getNext()/Prev(). Is iterating through the > parent Function's iterator the only solution? > * CallInst's constructors do not accept vectors anymore, but a double > pointer (!) instead. Why? > * Module::getNamedFunction() is now called Module::getFunction(). > * llvm/Transforms/Utils/Cloning.h's CloneFunctionInto() needs a > DenseMap as its third argument instead of an STL map. > * Pass's constructor now needs an intptr_t as explained in the updated > "Write your first pass"-document. > * In my own code, I can't use cout anymore without the std:: prefix. > * ConstantBool/Integral/Int are merged into ConstantInt. > * %llvm.dbg.subprogram.type's line number is now the 7th element; > its compile unit is now the 6th element. > * Argument names have got their argument index appended to their name in the > LLVM bitcode (e.g. "define void @f(i32 %Arg1, i32 %OtherArg2) {...}" instead > of "define void @f(i32 %Arg, i32 %OtherArg) {...}"). > * ... (there is probably more, as my app compiles by now, but is still > broken) > > Kind regards, > > Bram Adams > GH-SEL, INTEC, Ghent University (Belgium) > ??? > From fbrandne at mail.tuwien.ac.at Fri May 18 03:10:36 2007 From: fbrandne at mail.tuwien.ac.at (Florian Brandner) Date: Fri, 18 May 2007 10:10:36 +0200 Subject: [LLVMdev] instruction selector failure In-Reply-To: References: <464AF5DF.1010608@mail.tuwien.ac.at> Message-ID: <464D5F7C.10503@mail.tuwien.ac.at> Chris Lattner wrote: > On Wed, 16 May 2007, Florian Brandner wrote: > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070514/049609.html > > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070514/049608.html > > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070514/049606.html > > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070514/049603.html > thank you for the hint. > If this blocks a significant piece of software from building with LLVM > 2.0 though, we may reconsider. What does it break? the problem is caused by an internal application. it is not publicly available, so it should not be an issue for the release. thank you, florian From baldrick at free.fr Fri May 18 03:31:49 2007 From: baldrick at free.fr (Duncan Sands) Date: Fri, 18 May 2007 10:31:49 +0200 Subject: [LLVMdev] how to dump data stuctures of llvm in llvm-gcc In-Reply-To: <31ba424e0705172354m25d61d88sc1c283cdba02bcdc@mail.gmail.com> References: <31ba424e0705172354m25d61d88sc1c283cdba02bcdc@mail.gmail.com> Message-ID: <200705181031.49717.baldrick@free.fr> Hi Manish, > Can any one please tell me the option in llvm-gcc to dump data > structures of llvm and llvm IR. if you compile with -emit-llvm then the compiler outputs llvm IR if you compile with -c, and llvm assembler (bytecode in human readable form) if you compile with -S. I hope this helps, Duncan. From keith at tungstengraphics.com Fri May 18 04:49:58 2007 From: keith at tungstengraphics.com (Keith Whitwell) Date: Fri, 18 May 2007 10:49:58 +0100 Subject: [LLVMdev] Slides from Dev Meeting Message-ID: <464D76C6.7000706@tungstengraphics.com> I would have liked to attend the dev meeting, but unfortunately I'm unable to. Will slides and/or transcipts from the talks be available online somewhere? Keith From keith at tungstengraphics.com Fri May 18 05:23:24 2007 From: keith at tungstengraphics.com (Keith Whitwell) Date: Fri, 18 May 2007 11:23:24 +0100 Subject: [LLVMdev] llvm, gpu execution environments Message-ID: <464D7E9C.7080608@tungstengraphics.com> I'm interested in understanding the extent of the assumptions which llvm makes about the types of hardware it is capable of targeting. In particular, I'm investigating a proposal by Zack Rusin to use llvm as the shader compilation engine within Mesa, targeting GPU backends. I'm aware of the Apple GLSL compiler, and also I've seen the Vector LLVA paper. However, I'm not sure that either of these quite bridges the gap to the execution environment provided by modern GPUs. Though there are a couple of question marks, I'll pick the most obvious one: It seems that LLVA and by extension Vector-LLVA assumes that looping and branching control flow can be expressed in terms of a simple "br" branch operation. Typically GPU environments cannot provide such a facility as they tend to run 16, 32 or 64 simd threads all with the same program counter. Though this is a wide vector environment, each of the threads is typically a scalar program and at any branch point, some of those threads may take the branch and some not. So, to provide dynamic branching facilities in this environment, you end up with per-channel execution masks, and opcodes like "IF", "THEN", and "ELSE" which manipulate those per-channel masks, and use stack semantics for pushing and popping masks to emulate nested control structures. This is probably all very familiar to anybody who's thought about simd program execution. But it means that GPUs, and low-level GPU abstractions tend not to have branch instructions. The question then, is to what extent it is possible to target this type of execution environment with LLVM and the LLVA/Vector-LLVA ISAs??? Is it necessary (or feasible) to try to analyse LLVA programs and extract IF/THEN/ELSE semantics from a set of arbitary branch instructions? Is it possible to extend LLVA with these 'high level' control flow instructions and end up generating those instead of branches, and if so how does that affect the rest of LLVM? Is it for some reason just not feasible at all? Keith From manishagg22 at gmail.com Fri May 18 05:33:28 2007 From: manishagg22 at gmail.com (manish) Date: Fri, 18 May 2007 16:03:28 +0530 Subject: [LLVMdev] QUERY Message-ID: <31ba424e0705180333k549c9420m23bd761648cde6d5@mail.gmail.com> From manishagg22 at gmail.com Fri May 18 05:36:28 2007 From: manishagg22 at gmail.com (manishagg22 at gmail.com) Date: Fri, 18 May 2007 16:06:28 +0530 Subject: [LLVMdev] QUERY In-Reply-To: <31ba424e0705180333k549c9420m23bd761648cde6d5@mail.gmail.com> References: <31ba424e0705180333k549c9420m23bd761648cde6d5@mail.gmail.com> Message-ID: <31ba424e0705180336i4e478147ub9cf057eea22e611@mail.gmail.com> Hi All, I have a query regarding LLVM,Can LLVM IR can restore high level information of base language. Thanks and Regards, Manish On 5/18/07, manish wrote: > > From asl at math.spbu.ru Fri May 18 06:09:05 2007 From: asl at math.spbu.ru (Anton Korobeynikov) Date: Fri, 18 May 2007 15:09:05 +0400 Subject: [LLVMdev] QUERY In-Reply-To: <31ba424e0705180336i4e478147ub9cf057eea22e611.SS366SS@mail.gmail.com> References: <31ba424e0705180333k549c9420m23bd761648cde6d5@mail.gmail.com> <31ba424e0705180336i4e478147ub9cf057eea22e611.SS366SS@mail.gmail.com> Message-ID: <1179486545.28365.0.camel@asl.dorms.spbu.ru> Hello, > I have a query regarding LLVM,Can LLVM IR can restore high level > information of base language. It depends, what you're calling "high level information"... But answer is, in general, "no". -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University. From angray at beeb.net Fri May 18 10:02:42 2007 From: angray at beeb.net (Aaron Gray) Date: Fri, 18 May 2007 16:02:42 +0100 Subject: [LLVMdev] 2.0 Pre-release tarballs online References: <1b7701c798ce$02834230$0200a8c0@AMD2500> Message-ID: <1c3101c7995d$9644ad80$0200a8c0@AMD2500> >> On make check the bit intrinsics test is still failing but it works from >> the >> command line, strange ? > > Did Chris help you with this or is it still an issue? We did not resolve it. >> What files do you want from the nightly report, as I am not familiar with >> it >> ? > > in llvm-test, if you run the gmake TEST=nightly report command it will > generated a report.nightly.txt file. Thats what I want to see. The results on LLVM Test Results on mailing list. Cheers, Aaron >> I will be doing Cygwin tests next. >> >> Aaron >> >> ----- Original Message ----- >> From: "Tanya M. Lattner" >> To: "LLVM Developers Mailing List" >> Sent: Tuesday, May 15, 2007 9:23 AM >> Subject: [LLVMdev] 2.0 Pre-release tarballs online >> >> >>> >>> I've uploaded the 2.0 pre-release to this location: >>> http://llvm.org/prereleases/2.0/ >>> >>> If you have free time and would like to help test this release, please >>> download the appropriate tarballs from the website. >>> >>> Here are a few ways you can help test this release: >>> >>> 1) Download llvm-gcc4 binary and llvm. Compile and run make check. >>> >>> 2) Download llvm-gcc4 binary, llvm, and llvm-test. Compile, run make >>> check, and do "make ENABLE_OPTIMIZED=1 TEST=nightly report" in >>> llvm-test. >>> >>> 3) Compile llvm-gcc4 and llvm from source. Run 'make check'. >>> >>> 4) Compile llvm-gcc4 and llvm from source. Run 'make check' and do a >>> 'make >>> ENABLE_OPTIMIZED=1 TEST=nightly report' in llvm-test. >>> >>> It would also be helpful for someone to compile/test with objdir != >>> srcdir. >>> The 2.0 release defaults to a Release build, but you are welcome >>> to test with a Debug build as well. >>> >>> When reporting your results, please email the list and mention what >>> platform, which option you chose (1, 2, 3, or 4), and if you made any >>> configure changes (objdir != srcdir, or Debug build). Include the >>> dejagnu >>> test log or the nightly test report. >>> >>> Thanks, >>> Tanya Lattner >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>> >>> >>> -- >>> No virus found in this incoming message. >>> Checked by AVG Free Edition. >>> Version: 7.5.467 / Virus Database: 269.7.1/805 - Release Date: >>> 15/05/2007 >>> 10:47 >>> >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.467 / Virus Database: 269.7.3/809 - Release Date: 17/05/2007 > 17:18 > From rspencer at reidspencer.com Fri May 18 10:39:45 2007 From: rspencer at reidspencer.com (Reid Spencer) Date: Fri, 18 May 2007 15:39:45 +0000 Subject: [LLVMdev] Slides from Dev Meeting In-Reply-To: <464D76C6.7000706@tungstengraphics.com> References: <464D76C6.7000706@tungstengraphics.com> Message-ID: <1179502785.1233.693.camel@bashful.x10sys.com> Hi Keith, On Fri, 2007-05-18 at 10:49 +0100, Keith Whitwell wrote: > I would have liked to attend the dev meeting, but unfortunately I'm > unable to. Will slides and/or transcipts from the talks be available > online somewhere? We are planning to make both slides and video available a few days after the meeting. > > Keith > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From rspencer at reidspencer.com Fri May 18 10:47:54 2007 From: rspencer at reidspencer.com (Reid Spencer) Date: Fri, 18 May 2007 15:47:54 +0000 Subject: [LLVMdev] QUERY In-Reply-To: <31ba424e0705180336i4e478147ub9cf057eea22e611@mail.gmail.com> References: <31ba424e0705180333k549c9420m23bd761648cde6d5@mail.gmail.com> <31ba424e0705180336i4e478147ub9cf057eea22e611@mail.gmail.com> Message-ID: <1179503274.1233.702.camel@bashful.x10sys.com> Hi Manish, On Fri, 2007-05-18 at 16:06 +0530, manishagg22 at gmail.com wrote: > Hi All, > I have a query regarding LLVM,Can LLVM IR can restore high level > information of base language. As Anton mentioned, the general answer is "no". Once the translation from the source language to the LLVM IR has been completed, the high level information is lost. In some cases, given knowledge of the front end compiler, it might be possible to reconstruct the high level information from the LLVM IR. Additionally, a front end compiler could choose to emit additional information about the high level structure of the program to aid in the reconstitution of the source code. However, no compilers are known to do this currently. A case in point is the current debug support. The information necessary for debugging is provided by calls to intrinsic functions and global variables emitted directly into the LLVM IR stream. These are then recognized by the code generators and turned into the corresponding DWARF data. On another front, the HLVM project (http://hlvm.org/) will soon be integrated with LLVM. Although HLVM is incomplete at this point, it will in the future support doing what you want. HLVM supports an Abstract Syntax Tree (AST) which is very close to the syntax of the source language. HLVM will (optionally) allow you to embed the AST into the bitcode file so that both the LLVM IR and HLVM AST are in the same bitcode file. HLVM will provide a library that can call back to an application to reconstitute the AST and associate it with the LLVM IR constructs. None of this exists yet, I'm just letting you know future plans. Reid. > Thanks and Regards, > Manish > > On 5/18/07, manish wrote: > > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From bram.adams at ugent.be Fri May 18 11:12:35 2007 From: bram.adams at ugent.be (Bram Adams) Date: Fri, 18 May 2007 18:12:35 +0200 Subject: [LLVMdev] Antw.: 2.0 Pre-release tarballs online In-Reply-To: References: Message-ID: Hi, Op 18-mei-07, om 10:10 heeft Tanya M. Lattner het volgende geschreven: >> On Slackware 10.2 (GCC 3.3.6), I got an error during a debug build >> with the header files using uintptr_t (not recognised as a type). >> Putting "#include " in include/llvm/BasicBlock.h (llvm) >> and in "include/llvm/ValueSymbolTable.h" (frontend) resolved this. > > Ok. This is now fixed on the release branch. Thanks! The strange thing is that the configure process defines: #define HAVE_STDINT_H 1 However, without literally including stdint.h (which should be avoided as Reid mentioned) the compilation of AsmWriter.cpp goes wrong, although stdint.h, llvm/Support/DataTypes.h and inttypes.h are all mentioned in AsmWriter.d: if g++ -I/home/bram/workspace/svn/aspicere2/trunk/llvm-build/lib/ VMCore -I/home/bram/workspace/svn/aspicere2/trunk/llvm/lib/VMCore -I/ home/bram/workspace/svn/aspicere2/trunk/llvm-build/include -I/home/ bram/workspace/svn/aspicere2/trunk/llvm/include -I/home/bram/ workspace/svn/aspicere2/trunk/llvm-build/include -I/home/bram/ workspace/svn/aspicere2/trunk/llvm/include -D_GNU_SOURCE - D__STDC_LIMIT_MACROS -g -fno-exceptions -D_DEBUG -Woverloaded- virtual -pedantic -Wall -W -Wwrite-strings -Wno-long-long -Wunused - Wno-unused-parameter -c -MD -MT /home/bram/workspace/svn/aspicere2/ trunk/llvm-build/lib/VMCore/Debug/AsmWriter.o -MP -MF /home/bram/ workspace/svn/aspicere2/trunk/llvm-build/lib/VMCore/Debug/ AsmWriter.LACXXd /home/bram/workspace/svn/aspicere2/trunk/llvm/lib/ VMCore/AsmWriter.cpp -o /home/bram/workspace/svn/aspicere2/trunk/llvm- build/lib/VMCore/Debug/AsmWriter.o ;\ then /usr/bin/mv -f "/home/bram/workspace/svn/aspicere2/trunk/llvm- build/lib/VMCore/Debug/AsmWriter.LACXXd" "/home/bram/workspace/svn/ aspicere2/trunk/llvm-build/lib/VMCore/Debug/AsmWriter.d"; \ else /usr/bin/rm -f "/home/bram/workspace/svn/aspicere2/trunk/llvm- build/lib/VMCore/Debug/AsmWriter.LACXXd"; exit 1; fi In file included from /home/bram/workspace/svn/aspicere2/trunk/llvm/ include/llvm/Function.h:22, from /home/bram/workspace/svn/aspicere2/trunk/llvm/ include/llvm/Module.h:17, from /home/bram/workspace/svn/aspicere2/trunk/llvm/ include/llvm/Assembly/PrintModulePass.h:22, from /home/bram/workspace/svn/aspicere2/trunk/llvm/ lib/VMCore/AsmWriter.cpp:18: /home/bram/workspace/svn/aspicere2/trunk/llvm/include/llvm/ BasicBlock.h: In static member function `static unsigned int llvm::BasicBlock::getInstListOffset()': /home/bram/workspace/svn/aspicere2/trunk/llvm/include/llvm/ BasicBlock.h:197: error: syntax error before `;' token ... Should -DHAVE_STDINT_H be passed to the above command? > >> Also, I got linking errors while linking tblgen (see error.txt). >> Any ideas about this? > > I'm not really sure whats going on here and I can't reproduce this > since I don't have your setup. Its probably either an issue with > gcc or ld (try upgrading to 2.17.X if possible). If you can try to > investigate it further, that would be great. Then file a bug for it. Problem solved: compiling the 2.0 frontend from source had resulted in gcc, g++, ... instead of llvm-gcc, llvm-g++, ... After manually renaming them, compilation of LLVM was a breeze and the tests did not yield any unexpected failures (see attachment). Kind regards, Bram Adams GH-SEL, INTEC, Ghent University (Belgium) -------------- next part -------------- A non-text attachment was scrubbed... Name: x86.log.zip Type: application/zip Size: 19787 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20070518/d14c6703/attachment-0001.zip From rspencer at reidspencer.com Fri May 18 11:40:21 2007 From: rspencer at reidspencer.com (Reid Spencer) Date: Fri, 18 May 2007 16:40:21 +0000 Subject: [LLVMdev] Antw.: 2.0 Pre-release tarballs online In-Reply-To: References: Message-ID: <1179506421.1233.723.camel@bashful.x10sys.com> Hi Bram, On Fri, 2007-05-18 at 18:12 +0200, Bram Adams wrote: > Hi, > > Op 18-mei-07, om 10:10 heeft Tanya M. Lattner het volgende geschreven: > > >> On Slackware 10.2 (GCC 3.3.6), I got an error during a debug build > >> with the header files using uintptr_t (not recognised as a type). > >> Putting "#include " in include/llvm/BasicBlock.h (llvm) > >> and in "include/llvm/ValueSymbolTable.h" (frontend) resolved this. > > > > Ok. This is now fixed on the release branch. Thanks! > > The strange thing is that the configure process defines: > > #define HAVE_STDINT_H 1 > > However, without literally including stdint.h (which should be > avoided as Reid mentioned) the compilation of AsmWriter.cpp goes > wrong, What goes wrong? > although stdint.h, llvm/Support/DataTypes.h and inttypes.h are > all mentioned in AsmWriter.d: .. snip .. > Should -DHAVE_STDINT_H be passed to the above command? No, it is defined in include/llvm/Config/config.h which is an autoconf generated file and included in all LLVM compilations. > > > > >> Also, I got linking errors while linking tblgen (see error.txt). > >> Any ideas about this? > > > > I'm not really sure whats going on here and I can't reproduce this > > since I don't have your setup. Its probably either an issue with > > gcc or ld (try upgrading to 2.17.X if possible). If you can try to > > investigate it further, that would be great. Then file a bug for it. > > Problem solved: compiling the 2.0 frontend from source had resulted > in gcc, g++, ... instead of llvm-gcc, llvm-g++, ... After manually > renaming them, compilation of LLVM was a breeze and the tests did not > yield any unexpected failures (see attachment). Glad you figured that out. The build guidelines for llvm-gcc are in README.LLVM at the top level of the llvm-gcc source tree. It recommends making links. Some of us, however, also use the --program-prefix=llvm- option when configuring llvm-gcc which causes all programs to have an llvm- prefix. > > Kind regards, > > Bram Adams > GH-SEL, INTEC, Ghent University (Belgium) > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From angray at beeb.net Fri May 18 11:44:40 2007 From: angray at beeb.net (Aaron Gray) Date: Fri, 18 May 2007 17:44:40 +0100 Subject: [LLVMdev] 2.0 Pre-release tarballs online References: <1b7701c798ce$02834230$0200a8c0@AMD2500> Message-ID: <1cba01c7996b$d452e020$0200a8c0@AMD2500> >> On make check the bit intrinsics test is still failing but it works from >> the >> command line, strange ? > > Did Chris help you with this or is it still an issue? Yes, but we did not resolve it, its trivial anyway, time better spent else where. >> What files do you want from the nightly report, as I am not familiar with >> it >> ? > > in llvm-test, if you run the gmake TEST=nightly report command it will > generated a report.nightly.txt file. Thats what I want to see. Okay test results on the LLVM Test results mailing list. Doing Cygwin tests now. Thanks, Aaron > > Thanks! > > -Tanya > >> >> I will be doing Cygwin tests next. >> >> Aaron >> >> ----- Original Message ----- >> From: "Tanya M. Lattner" >> To: "LLVM Developers Mailing List" >> Sent: Tuesday, May 15, 2007 9:23 AM >> Subject: [LLVMdev] 2.0 Pre-release tarballs online >> >> >>> >>> I've uploaded the 2.0 pre-release to this location: >>> http://llvm.org/prereleases/2.0/ >>> >>> If you have free time and would like to help test this release, please >>> download the appropriate tarballs from the website. >>> >>> Here are a few ways you can help test this release: >>> >>> 1) Download llvm-gcc4 binary and llvm. Compile and run make check. >>> >>> 2) Download llvm-gcc4 binary, llvm, and llvm-test. Compile, run make >>> check, and do "make ENABLE_OPTIMIZED=1 TEST=nightly report" in >>> llvm-test. >>> >>> 3) Compile llvm-gcc4 and llvm from source. Run 'make check'. >>> >>> 4) Compile llvm-gcc4 and llvm from source. Run 'make check' and do a >>> 'make >>> ENABLE_OPTIMIZED=1 TEST=nightly report' in llvm-test. >>> >>> It would also be helpful for someone to compile/test with objdir != >>> srcdir. >>> The 2.0 release defaults to a Release build, but you are welcome >>> to test with a Debug build as well. >>> >>> When reporting your results, please email the list and mention what >>> platform, which option you chose (1, 2, 3, or 4), and if you made any >>> configure changes (objdir != srcdir, or Debug build). Include the >>> dejagnu >>> test log or the nightly test report. >>> >>> Thanks, >>> Tanya Lattner >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>> >>> >>> -- >>> No virus found in this incoming message. >>> Checked by AVG Free Edition. >>> Version: 7.5.467 / Virus Database: 269.7.1/805 - Release Date: >>> 15/05/2007 >>> 10:47 >>> >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.467 / Virus Database: 269.7.3/809 - Release Date: 17/05/2007 > 17:18 > From keith at tungstengraphics.com Fri May 18 12:13:09 2007 From: keith at tungstengraphics.com (Keith Whitwell) Date: Fri, 18 May 2007 18:13:09 +0100 Subject: [LLVMdev] Slides from Dev Meeting In-Reply-To: <1179502785.1233.693.camel@bashful.x10sys.com> References: <464D76C6.7000706@tungstengraphics.com> <1179502785.1233.693.camel@bashful.x10sys.com> Message-ID: <464DDEA5.1070704@tungstengraphics.com> Reid Spencer wrote: > Hi Keith, > > On Fri, 2007-05-18 at 10:49 +0100, Keith Whitwell wrote: >> I would have liked to attend the dev meeting, but unfortunately I'm >> unable to. Will slides and/or transcipts from the talks be available >> online somewhere? > > We are planning to make both slides and video available a few days after > the meeting. Thanks, I look forward to seeing them. Out of interest, has my second message come through (regarding GPU execution environments)? I see it in the archives, but I never got the copy back myself... Keith From sabre at nondot.org Fri May 18 13:16:15 2007 From: sabre at nondot.org (Chris Lattner) Date: Fri, 18 May 2007 11:16:15 -0700 (PDT) Subject: [LLVMdev] instruction selector failure In-Reply-To: <464D5F7C.10503@mail.tuwien.ac.at> References: <464AF5DF.1010608@mail.tuwien.ac.at> <464D5F7C.10503@mail.tuwien.ac.at> Message-ID: On Fri, 18 May 2007, Florian Brandner wrote: >> If this blocks a significant piece of software from building with LLVM >> 2.0 though, we may reconsider. What does it break? > > the problem is caused by an internal application. it is not publicly > available, so it should not be an issue for the release. Ok, as it turns out, we ended up deciding to merge it into the release, so llvm 2.0 should have the fix. -Chris -- http://nondot.org/sabre/ http://llvm.org/ From tonic at nondot.org Fri May 18 13:28:25 2007 From: tonic at nondot.org (Tanya M. Lattner) Date: Fri, 18 May 2007 11:28:25 -0700 (PDT) Subject: [LLVMdev] Updated: 2.0 Pre-release tarballs online In-Reply-To: References: Message-ID: I've updated the pre-release tarballs online. I'm also extending the testing completion date to May 22nd at 5pm PDT. The new release target date is May 23rd. If you have any free time, please give the new pre-release a try. Thanks to all who have tested LLVM! -Tanya P.S. Documentation review should still be completed today! Thanks! > I've uploaded the 2.0 pre-release to this location: > http://llvm.org/prereleases/2.0/ > > If you have free time and would like to help test this release, please > download the appropriate tarballs from the website. > > Here are a few ways you can help test this release: > > 1) Download llvm-gcc4 binary and llvm. Compile and run make check. > > 2) Download llvm-gcc4 binary, llvm, and llvm-test. Compile, run make check, > and do "make ENABLE_OPTIMIZED=1 TEST=nightly report" in llvm-test. > > 3) Compile llvm-gcc4 and llvm from source. Run 'make check'. > > 4) Compile llvm-gcc4 and llvm from source. Run 'make check' and do a 'make > ENABLE_OPTIMIZED=1 TEST=nightly report' in llvm-test. > > It would also be helpful for someone to compile/test with objdir != srcdir. > The 2.0 release defaults to a Release build, but you are welcome to test with > a Debug build as well. > > When reporting your results, please email the list and mention what platform, > which option you chose (1, 2, 3, or 4), and if you made any configure changes > (objdir != srcdir, or Debug build). Include the dejagnu test log or the > nightly test report. > > Thanks, > Tanya Lattner > > From angray at beeb.net Fri May 18 12:40:45 2007 From: angray at beeb.net (Aaron Gray) Date: Fri, 18 May 2007 18:40:45 +0100 Subject: [LLVMdev] GCC Mainline and GCC 4.3 STL mods Message-ID: <1ce401c79973$aa5da0e0$0200a8c0@AMD2500> Mainline and 4.3 branch GCC libstdc++ have removed string.h access from STL map etc. As a result several LLVM System files and others do not compile on mainline and 4.3. Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20070518/5ad77408/attachment.html From sabre at nondot.org Fri May 18 13:55:32 2007 From: sabre at nondot.org (Chris Lattner) Date: Fri, 18 May 2007 11:55:32 -0700 (PDT) Subject: [LLVMdev] GCC Mainline and GCC 4.3 STL mods In-Reply-To: <1ce401c79973$aa5da0e0$0200a8c0@AMD2500> References: <1ce401c79973$aa5da0e0$0200a8c0@AMD2500> Message-ID: On Fri, 18 May 2007, Aaron Gray wrote: > Mainline and 4.3 branch GCC libstdc++ have removed string.h access from > STL map etc. > > As a result several LLVM System files and others do not compile on > mainline and 4.3. Okay, will you please prepare and submit a patch that adds the needed #include's? -Chris -- http://nondot.org/sabre/ http://llvm.org/ From angray at beeb.net Fri May 18 13:11:46 2007 From: angray at beeb.net (Aaron Gray) Date: Fri, 18 May 2007 19:11:46 +0100 Subject: [LLVMdev] GCC Mainline and GCC 4.3 STL mods References: <1ce401c79973$aa5da0e0$0200a8c0@AMD2500> Message-ID: <1d1b01c79977$ffaa5760$0200a8c0@AMD2500> Chris, I am doing Cygwin builds at the moment so it will not be immediately attended to. Do you want it done for 2.0 ? Or could it be a post 2.0 patch which I suggest as 4.3 branch is not up for a release too soon ? Aaron ----- Original Message ----- From: "Chris Lattner" To: "LLVM Developers Mailing List" Sent: Friday, May 18, 2007 7:55 PM Subject: Re: [LLVMdev] GCC Mainline and GCC 4.3 STL mods > On Fri, 18 May 2007, Aaron Gray wrote: >> Mainline and 4.3 branch GCC libstdc++ have removed string.h access from >> STL map etc. >> >> As a result several LLVM System files and others do not compile on >> mainline and 4.3. > > Okay, will you please prepare and submit a patch that adds the needed > #include's? > > -Chris > > -- > http://nondot.org/sabre/ > http://llvm.org/ > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.467 / Virus Database: 269.7.3/809 - Release Date: 17/05/2007 > 17:18 > From sabre at nondot.org Fri May 18 14:20:18 2007 From: sabre at nondot.org (Chris Lattner) Date: Fri, 18 May 2007 12:20:18 -0700 (PDT) Subject: [LLVMdev] GCC Mainline and GCC 4.3 STL mods In-Reply-To: <1d1b01c79977$ffaa5760$0200a8c0@AMD2500> References: <1ce401c79973$aa5da0e0$0200a8c0@AMD2500> <1d1b01c79977$ffaa5760$0200a8c0@AMD2500> Message-ID: On Fri, 18 May 2007, Aaron Gray wrote: > I am doing Cygwin builds at the moment so it will not be immediately > attended to. ok > Do you want it done for 2.0 ? Or could it be a post 2.0 patch which I > suggest as 4.3 branch is not up for a release too soon ? I think this is LLVM 2.1 material, thanks! We will release 2.1 *well* before gcc 4.3 is released. -Chris > ----- Original Message ----- > From: "Chris Lattner" > To: "LLVM Developers Mailing List" > Sent: Friday, May 18, 2007 7:55 PM > Subject: Re: [LLVMdev] GCC Mainline and GCC 4.3 STL mods > > >> On Fri, 18 May 2007, Aaron Gray wrote: >>> Mainline and 4.3 branch GCC libstdc++ have removed string.h access from >>> STL map etc. >>> >>> As a result several LLVM System files and others do not compile on >>> mainline and 4.3. >> >> Okay, will you please prepare and submit a patch that adds the needed >> #include's? >> >> -Chris >> >> -- >> http://nondot.org/sabre/ >> http://llvm.org/ >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> >> -- >> No virus found in this incoming message. >> Checked by AVG Free Edition. >> Version: 7.5.467 / Virus Database: 269.7.3/809 - Release Date: 17/05/2007 >> 17:18 >> > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > -Chris -- http://nondot.org/sabre/ http://llvm.org/ From bram.adams at ugent.be Fri May 18 14:40:09 2007 From: bram.adams at ugent.be (Bram Adams) Date: Fri, 18 May 2007 21:40:09 +0200 Subject: [LLVMdev] Antw.: 2.0 Pre-release tarballs online In-Reply-To: <1179506421.1233.723.camel@bashful.x10sys.com> References: <1179506421.1233.723.camel@bashful.x10sys.com> Message-ID: Hi, Op 18-mei-07, om 18:40 heeft Reid Spencer het volgende geschreven: > What goes wrong? Everything's fine now. Forgot to look at Tanya's changes (#include "llvm/Support/DataTypes.h") :-)... > Glad you figured that out. The build guidelines for llvm-gcc are in > README.LLVM at the top level of the llvm-gcc source tree. It > recommends > making links. Some of us, however, also use the --program-prefix=llvm- > option when configuring llvm-gcc which causes all programs to have an > llvm- prefix. OK, I'lll use the latter option from now on. Kind regards, Bram Adams GH-SEL, INTEC, Ghent University (Belgium) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20070518/f02d6594/attachment.html From tonic at nondot.org Fri May 18 15:42:13 2007 From: tonic at nondot.org (Tanya M. Lattner) Date: Fri, 18 May 2007 13:42:13 -0700 (PDT) Subject: [LLVMdev] Antw.: 2.0 Pre-release tarballs online In-Reply-To: References: <1179506421.1233.723.camel@bashful.x10sys.com> Message-ID: > Everything's fine now. Forgot to look at Tanya's changes (#include > "llvm/Support/DataTypes.h") :-)... Thats great news! >> Glad you figured that out. The build guidelines for llvm-gcc are in >> README.LLVM at the top level of the llvm-gcc source tree. It recommends >> making links. Some of us, however, also use the --program-prefix=llvm- >> option when configuring llvm-gcc which causes all programs to have an >> llvm- prefix. > > OK, I'lll use the latter option from now on. I'm actually going to change the README.LLVM to suggest people use --program-prefix=llvm-. I have made the same mistake you did by using the wrong gcc. Its easy to do. Thanks again! -Tanya From bram.adams at ugent.be Fri May 18 16:01:58 2007 From: bram.adams at ugent.be (Bram Adams) Date: Fri, 18 May 2007 23:01:58 +0200 Subject: [LLVMdev] API changes (was Antw.: 2.0 Pre-release tarballs online) In-Reply-To: References: Message-ID: <0618F80F-6E10-4817-9C2E-6CBA63877F81@ugent.be> Hi, Op 18-mei-07, om 00:11 heeft Chris Lattner het volgende geschreven: > I'll mention this in the release notes. The darwin linker in 10.5 > (not > yet released) supports llvm, and there is an experimental patch for > binutils, but I don't knows its current state. OK, I'll try out the latter (and wait for Leopard in the meantime :-)). > This is all very useful. If you have any more additions, please > let me > know. Thanks again, You're welcome, here's some more: * The various IntXTy's are not considered primitive anymore by e.g. Type::isPrimitiveType(). * It seems that a C-call like printf("---\n") is transformed to puts ("---") in the LLVM IR instead of keeping it a printf. What are the circumstances in which this happens? Do other similar conversions occur? Can this be turned off (lower optimisation level?)? Manually replacing the puts-calls by a printf-call is not straightforward, as the argument should be appended a '\n' (implicit with puts). Kind regards, Bram Adams GH-SEL, INTEC, Ghent University (Belgium) From asl at math.spbu.ru Fri May 18 16:35:40 2007 From: asl at math.spbu.ru (Anton Korobeynikov) Date: Sat, 19 May 2007 01:35:40 +0400 Subject: [LLVMdev] API changes (was Antw.: 2.0 Pre-release tarballs online) In-Reply-To: <0618F80F-6E10-4817-9C2E-6CBA63877F81.SS1239SS@ugent.be> References: <0618F80F-6E10-4817-9C2E-6CBA63877F81.SS1239SS@ugent.be> Message-ID: <1179524140.28365.14.camel@asl.dorms.spbu.ru> Hello, Bram > * It seems that a C-call like printf("---\n") is transformed to puts > ("---") in the LLVM IR instead of keeping it a printf. What are the > circumstances in which this happens? Do other similar conversions > occur? Can this be turned off (lower optimisation level?)? Manually > replacing the puts-calls by a printf-call is not straightforward, as > the argument should be appended a '\n' (implicit with puts). This transformation is performed via simplify-libcalls optimization pass. You can look into corresponding source to check for list of xforms. -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University. From sabre at nondot.org Fri May 18 17:39:56 2007 From: sabre at nondot.org (Chris Lattner) Date: Fri, 18 May 2007 15:39:56 -0700 (PDT) Subject: [LLVMdev] API changes (was Antw.: 2.0 Pre-release tarballs online) In-Reply-To: <1179524140.28365.14.camel@asl.dorms.spbu.ru> References: <0618F80F-6E10-4817-9C2E-6CBA63877F81.SS1239SS@ugent.be> <1179524140.28365.14.camel@asl.dorms.spbu.ru> Message-ID: On Sat, 19 May 2007, Anton Korobeynikov wrote: >> * It seems that a C-call like printf("---\n") is transformed to puts >> ("---") in the LLVM IR instead of keeping it a printf. What are the >> circumstances in which this happens? Do other similar conversions >> occur? Can this be turned off (lower optimisation level?)? Manually >> replacing the puts-calls by a printf-call is not straightforward, as >> the argument should be appended a '\n' (implicit with puts). > This transformation is performed via simplify-libcalls optimization > pass. You can look into corresponding source to check for list of > xforms. Anton is right. You should be able to use -fno-builtins to disable this. -Chris -- http://nondot.org/sabre/ http://llvm.org/ From zaks at jpl.nasa.gov Fri May 18 18:08:07 2007 From: zaks at jpl.nasa.gov (Anna Zaks) Date: Fri, 18 May 2007 16:08:07 -0700 Subject: [LLVMdev] Access to LLVM CVS repository Message-ID: <464E31D7.8090805@jpl.nasa.gov> Hi, I am an intern at JPL and just started working on a new project that involves using LLVM for model checking. It seems that you are quite close to the LLVM 2.0 release date. Since it is a "big" release, I'd prefer to start with the latest code. Is it possible to get access to LLVM CVS repository? Thank you, Anna. From tonic at nondot.org Fri May 18 19:57:05 2007 From: tonic at nondot.org (Tanya M. Lattner) Date: Fri, 18 May 2007 17:57:05 -0700 (PDT) Subject: [LLVMdev] Access to LLVM CVS repository In-Reply-To: <464E31D7.8090805@jpl.nasa.gov> References: <464E31D7.8090805@jpl.nasa.gov> Message-ID: > I am an intern at JPL and just started working on a new project that > involves using LLVM for model checking. > > It seems that you are quite close to the LLVM 2.0 release date. Since it > is a "big" release, I'd prefer to start with the latest code. Is it > possible to get access to LLVM CVS repository? Instructions are here: http://llvm.org/docs/GettingStarted.html#checkout -Tanya > > Thank you, > Anna. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From sabre at nondot.org Sat May 19 03:01:57 2007 From: sabre at nondot.org (Chris Lattner) Date: Sat, 19 May 2007 01:01:57 -0700 (PDT) Subject: [LLVMdev] llvm, gpu execution environments In-Reply-To: <464D7E9C.7080608@tungstengraphics.com> References: <464D7E9C.7080608@tungstengraphics.com> Message-ID: On Fri, 18 May 2007, Keith Whitwell wrote: > I'm interested in understanding the extent of the assumptions which llvm > makes about the types of hardware it is capable of targeting. Different pieces of the compiler make different assumptions. In particular, the code generator we ship is good for targetting certain classes of devices, but isn't fully general (it doesn't help if you're synthesizing a netlist from llvm, for example). > In particular, I'm investigating a proposal by Zack Rusin to use llvm as > the shader compilation engine within Mesa, targeting GPU backends. Ok > It seems that LLVA and by extension Vector-LLVA assumes that looping and > branching control flow can be expressed in terms of a simple "br" branch > operation. LLVA is not a part of LLVM, so I won't answer for it. > Typically GPU environments cannot provide such a facility as they tend > to run 16, 32 or 64 simd threads all with the same program counter. > Though this is a wide vector environment, each of the threads is > typically a scalar program and at any branch point, some of those > threads may take the branch and some not. So, to provide dynamic > branching facilities in this environment, you end up with per-channel > execution masks, and opcodes like "IF", "THEN", and "ELSE" which > manipulate those per-channel masks, and use stack semantics for pushing > and popping masks to emulate nested control structures. Right, it's basically a form of predication. > This is probably all very familiar to anybody who's thought about simd > program execution. But it means that GPUs, and low-level GPU > abstractions tend not to have branch instructions. > > The question then, is to what extent it is possible to target this type > of execution environment with LLVM and the LLVA/Vector-LLVA ISAs??? > Is it necessary (or feasible) to try to analyse LLVA programs and > extract IF/THEN/ELSE semantics from a set of arbitary branch instructions? > Is it possible to extend LLVA with these 'high level' control flow > instructions and end up generating those instead of branches, and if so > how does that affect the rest of LLVM? The code generator and llvm should be able to handle this just fine, with only minimal extensions. Basically, you want to model this as predicated execution, and you want the code generator to predicate away as many branches etc as possible. One observation can be made though: there will always be some programs that you can't map onto the hardware. For example, if you don't have branches, you can't do loops that execute for a variable number of iterations. As such, I'd structure the compiler as a typical code generator with an early predication pass that flattens branches. If you get to the end of the codegen and have some dynamic branches left, you detect the error condition and reject the shader from the hardware path (so you have to emulate it in software). Does this make sense? -Chris -- http://nondot.org/sabre/ http://llvm.org/ From keith at tungstengraphics.com Sat May 19 02:57:25 2007 From: keith at tungstengraphics.com (Keith Whitwell) Date: Sat, 19 May 2007 08:57:25 +0100 Subject: [LLVMdev] llvm, gpu execution environments In-Reply-To: References: <464D7E9C.7080608@tungstengraphics.com> Message-ID: <464EADE5.300@tungstengraphics.com> Chris Lattner wrote: > On Fri, 18 May 2007, Keith Whitwell wrote: >> I'm interested in understanding the extent of the assumptions which llvm >> makes about the types of hardware it is capable of targeting. > > Different pieces of the compiler make different assumptions. In > particular, the code generator we ship is good for targetting certain > classes of devices, but isn't fully general (it doesn't help if you're > synthesizing a netlist from llvm, for example). > >> In particular, I'm investigating a proposal by Zack Rusin to use llvm as >> the shader compilation engine within Mesa, targeting GPU backends. > > Ok > >> It seems that LLVA and by extension Vector-LLVA assumes that looping and >> branching control flow can be expressed in terms of a simple "br" branch >> operation. > > LLVA is not a part of LLVM, so I won't answer for it. OK, I guess I misunderstood the papers I pulled down - my impression was that at some stage programs in llvm would be represented in LLVA. What, out of interest, is the relationship between LLVM and LLVA? >> Typically GPU environments cannot provide such a facility as they tend >> to run 16, 32 or 64 simd threads all with the same program counter. >> Though this is a wide vector environment, each of the threads is >> typically a scalar program and at any branch point, some of those >> threads may take the branch and some not. So, to provide dynamic >> branching facilities in this environment, you end up with per-channel >> execution masks, and opcodes like "IF", "THEN", and "ELSE" which >> manipulate those per-channel masks, and use stack semantics for pushing >> and popping masks to emulate nested control structures. > > Right, it's basically a form of predication. Yes, a set of high-level-ish instructions layered on dynamic predication to give a very close match to the normally understood dynamic branching and looping constructs we're all familiar with. It's initially quite odd to see something like "ELSE" or "WHILE" as hardware opcodes, but it makes sense under the hood. >> This is probably all very familiar to anybody who's thought about simd >> program execution. But it means that GPUs, and low-level GPU >> abstractions tend not to have branch instructions. >> >> The question then, is to what extent it is possible to target this type >> of execution environment with LLVM and the LLVA/Vector-LLVA ISAs??? >> Is it necessary (or feasible) to try to analyse LLVA programs and >> extract IF/THEN/ELSE semantics from a set of arbitary branch instructions? >> Is it possible to extend LLVA with these 'high level' control flow >> instructions and end up generating those instead of branches, and if so >> how does that affect the rest of LLVM? > > The code generator and llvm should be able to handle this just fine, with > only minimal extensions. > > Basically, you want to model this as predicated execution, and you want > the code generator to predicate away as many branches etc as possible. > > One observation can be made though: there will always be some programs > that you can't map onto the hardware. For example, if you don't have > branches, you can't do loops that execute for a variable number of > iterations. Actually, you can - there is a program counter, the loop keeps executing until the execution mask reaches zero. Likewise branches are dynamic. > As such, I'd structure the compiler as a typical code generator with an > early predication pass that flattens branches. If you get to the end of > the codegen and have some dynamic branches left, you detect the error > condition and reject the shader from the hardware path (so you have to > emulate it in software). The hardware *does* support dynamic branching, and looping, provided it is expressed in IF/THEN/ELSE, LOOP/BREAK/CONTINUE/ENDLOOP type instructions. Even CALL/RETURN. The only thing it can't do is execute something like "GOTO" or "BRANCH" dynamically. > Does this make sense? Yes, but at slight cross-purposes. There are no cases where compilation should fail to produce a hardware executable result, within the constraints of the high-level language we are compiling. Dynamic branches and looping are entirely within the capability of the hardware, provided they are expressed in terms of the hardware IF/THEN/ELSE, LOOP/ENDLOOP, etc, opcodes. But it seems like my initial understanding of the intermediate representation within llvm is incorrect & I probably should just dive into the source to figure out what's going on. My concern was that llva throws away the information that I'd probably need to reconstruct these high-level opcodes required by the hardware - if the code generator can come in at a higher level while that information still exists, then a lot of things get easier. Keith From vadve at uiuc.edu Sat May 19 16:49:55 2007 From: vadve at uiuc.edu (Vikram S. Adve) Date: Sat, 19 May 2007 16:49:55 -0500 Subject: [LLVMdev] llvm, gpu execution environments In-Reply-To: <464EADE5.300@tungstengraphics.com> References: <464D7E9C.7080608@tungstengraphics.com> <464EADE5.300@tungstengraphics.com> Message-ID: <20D1B9F3-08E2-4897-8962-DACA75C51EB2@uiuc.edu> On May 19, 2007, at 2:57 AM, Keith Whitwell wrote: >>> It seems that LLVA and by extension Vector-LLVA assumes that >>> looping and >>> branching control flow can be expressed in terms of a simple "br" >>> branch >>> operation. >> >> LLVA is not a part of LLVM, so I won't answer for it. > > OK, I guess I misunderstood the papers I pulled down - my > impression was > that at some stage programs in llvm would be represented in LLVA. > > What, out of interest, is the relationship between LLVM and LLVA? LLVA is a research project developing a more complete virtual architecture, starting with the LLVM ISA as a basis. This enables us to use the LLVM infrastructure directly in our work. The vector LLVA work was a short-term project led by Rob Bocchino and me, developing a general set of vector extensions to the instruction set, but we are no longer working on this. Our main focus in the LLVA project today is on a virtual machine approach for enforcing memory safety and security. We call this Secure Virtual Architecture (SVA). --Vikram http://www.cs.uiuc.edu/~vadve http://llvm.org From lee225 at uiuc.edu Sun May 20 00:01:22 2007 From: lee225 at uiuc.edu (Seung Jae Lee) Date: Sun, 20 May 2007 00:01:22 -0500 (CDT) Subject: [LLVMdev] Error while compilation of llvm-as Message-ID: <20070520000122.APY28548@expms2.cites.uiuc.edu> Hello, LLVM guys. While compliling llvm-as(LLVM ver. 1.9), I got an error looks like this: (I haven't modified any part in llvm-as and I just compiled it but....) ------------------------------------------------------------------- Debug Error! Program: ...\llvm-as.exe Module: ...\llvm-as.exe File: c:\usr\share\bison.simple Line:561 Run-Time Check Failure #3 - The variable 'yyval' is being used without being defined. ------------------------------------------------------------------- This 'yyval' is used in yyparse() in llvmAsmParser.y:868. Oh.. I forgot to say I used Visual Studio for this compile. Can you help me, if you have any idea w.r.t this? Thanks, Seung Jae Lee From bram.adams at ugent.be Sun May 20 16:21:39 2007 From: bram.adams at ugent.be (Bram Adams) Date: Sun, 20 May 2007 23:21:39 +0200 Subject: [LLVMdev] API changes (was Antw.: 2.0 Pre-release tarballs online) In-Reply-To: References: <0618F80F-6E10-4817-9C2E-6CBA63877F81.SS1239SS@ugent.be> <1179524140.28365.14.camel@asl.dorms.spbu.ru> Message-ID: Hi, Op 19-mei-07, om 00:39 heeft Chris Lattner het volgende geschreven: > Anton is right. You should be able to use -fno-builtins to disable > this. Thanks, that did the trick. Some final remarks (my app works again :-)): * llvm.va_start and similar intrinsics now have an i8* arg instead of an sbyte** * For some reason the Arguments of a Function are now circularly linked, i.e. getPrev()/Next() does not yield 0 when the first Argument is reached, but jumps back to the last one. I experienced this with a loop I was using to find out the index of an Argument. It relied on the fact that getPrev() would eventually give 0, which worked in previous LLVM versions. On a related note: while using llvmc I have some test cases where the following error now pops up on Linux X86 (not on OSX): : CommandLine Error: Argument 'debug' defined more than once! llvmc: CommandLine Error: Argument 'debug' defined more than once! These are the arguments I provide to llvmc (I need the -disable-opt as some of the standard passes absolutely need to occur before my passes, and the rest must come afterwards): llvmc --config-dir ${ASPICERE2_SRC}/config/ -Tlnk="-L${LLVM_FRONT}/ lib" -Tlnk="-L${ASPICERE2_INSTALL}/lib" -Tlnk="-L${SWI_LIB}" -Tlnk="- load=${ASPICERE2_INSTALL}/lib/weaver" -Tlnk="-load=$ {ASPICERE2_INSTALL}/lib/native" -Tlnk="-disable-opt" -Tlnk="- constmerge" -Tlnk="-globalsmodref-aa" -Tlnk="-reify" -Tlnk="-match" - Tlnk="-weave" -Tlnk="-globalsmodref-aa" -Tlnk="-internalize" -Tlnk="- ipsccp" -Tlnk="-globalopt" -Tlnk="-constmerge" -Tlnk="-deadargelim" - Tlnk="-instcombine" -Tlnk="-inline" -Tlnk="-prune-eh" -Tlnk="- globalopt" -Tlnk="-globaldce" -Tlnk="-argpromotion" -Tlnk="- instcombine" -Tlnk="-scalarrepl" -Tlnk="-globalsmodref-aa" -Tlnk="- licm" -Tlnk="-load-vn" -Tlnk="-gcse" -Tlnk="-dse" -Tlnk="- instcombine" -Tlnk="-simplifycfg" -Tlnk="-globaldce" $FILTERED_ARGS $ASPECT_STRING_TO_C Variable $FILTERED_ARGS contains some .c files and also the -o switch with the name of the resulting binary, while $ASPECT_STRING_TO_C contains another number of .c files. The weird thing (besides that I only experience this error on Linux) is that although all my test cases use llvmc, only two fail with this error without a clear reason. Any ideas on this? Kind regards, Bram Adams GH-SEL, INTEC, Ghent University (Belgium) From bjchambers at gmail.com Sun May 20 21:28:31 2007 From: bjchambers at gmail.com (Ben Chambers) Date: Sun, 20 May 2007 22:28:31 -0400 Subject: [LLVMdev] Question about the new version of LLVM GCC Message-ID: I noticed the following line in the output of LLVM GCC and was wondering what it meant: "alloca point" = bitcast i32 0 to i32 ; [#uses=0] I wasn't aware that a string was a valid left hand side, but considering the fact that the instruction is basically pointless (doesn't do anything, and is never used), I'm guessing that it instead serves to mark the end of the allocas for that function. Is this correct? If not, what does the instruction mean/do? Thanks, Ben Chambers From sabre at nondot.org Mon May 21 01:27:44 2007 From: sabre at nondot.org (Chris Lattner) Date: Sun, 20 May 2007 23:27:44 -0700 (PDT) Subject: [LLVMdev] Question about the new version of LLVM GCC In-Reply-To: References: Message-ID: On Sun, 20 May 2007, Ben Chambers wrote: > I noticed the following line in the output of LLVM GCC and was > wondering what it meant: > "alloca point" = bitcast i32 0 to i32 ; [#uses=0] > I wasn't aware that a string was a valid left hand side, but LLVM allows arbitrary characters to be in the names of values. For simple things, it uses %foo, for complex things, it uses quoted strings (in this case, due to the space). > considering the fact that the instruction is basically pointless > (doesn't do anything, and is never used), I'm guessing that it instead > serves to mark the end of the allocas for that function. Is this > correct? If not, what does the instruction mean/do? The LLVM APIs make it easy, fast and convenient to insert an instruction before another one. The llvm-gcc f.e. uses this bitcast as an anchor to insert (you guessed it) allocas. -Chris -- http://nondot.org/sabre/ http://llvm.org/ From manishagg22 at gmail.com Mon May 21 05:25:07 2007 From: manishagg22 at gmail.com (manish) Date: Mon, 21 May 2007 15:55:07 +0530 Subject: [LLVMdev] regarding the high level design of GCC-LLVM Message-ID: <31ba424e0705210325p1c375692t46b253998459d2bc@mail.gmail.com> Hi ALL, Can anyone please tell me how LLVM part interact with GCC FE( i mean parser and lexer). I want to ask how and where tree data structures are converted into llvm data structures. Thanks and Regards, Manish From fbrandne at mail.tuwien.ac.at Mon May 21 06:32:50 2007 From: fbrandne at mail.tuwien.ac.at (Florian Brandner) Date: Mon, 21 May 2007 13:32:50 +0200 Subject: [LLVMdev] instruction writing two successive registers Message-ID: <46518362.4060200@mail.tuwien.ac.at> hi, the architecture that we are compiling for has a special vector shuffle instruction, which writes two successive registers (Rn and Rn+1). i have defined intrinsics to generate the instruction, and a special register class for the register pairs. in addition i have two EXTRACT operations which allow to access either the first or second subregister of a pair (using moves). the pair register class is used only for this purpose and may not occur in other operations. this works fine. except for the extra moves generated by the EXTRACT, which can not be eliminated by coalescing, due to the differing register classes. here is a small example: // Pn is a register pair // 'a' and 'b' are regular registers Pn = shuffle(x, y) a = extract_lo(Pn) // which is a = Rn, b = extract_hi(Pn) // which is b = Rn+1 here it would be nice to assign 'a' to the first subregister of Pn (Rn), and b to the second (Rn+1). instead of using the pair register class, i also thought about adding a register constraint - something like TIED_TO_NEXT. can anyone give me an advise how to handle this special instruction? thank you, florian From rspencer at reidspencer.com Mon May 21 09:50:48 2007 From: rspencer at reidspencer.com (Reid Spencer) Date: Mon, 21 May 2007 07:50:48 -0700 Subject: [LLVMdev] regarding the high level design of GCC-LLVM In-Reply-To: <31ba424e0705210325p1c375692t46b253998459d2bc@mail.gmail.com> References: <31ba424e0705210325p1c375692t46b253998459d2bc@mail.gmail.com> Message-ID: <1179759048.9168.2.camel@bashful.x10sys.com> On Mon, 2007-05-21 at 15:55 +0530, manish wrote: > Hi ALL, > Can anyone please tell me how LLVM part interact with GCC FE( i mean > parser and lexer). > I want to ask how and where tree data structures are converted into > llvm data structures. In llvm-gcc, the types are converted in gcc/llvm-types.cpp and the values are converted in llvm-convert.cpp. Reid. > Thanks and Regards, > Manish > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From asl at math.spbu.ru Mon May 21 12:59:01 2007 From: asl at math.spbu.ru (Anton Korobeynikov) Date: Mon, 21 May 2007 21:59:01 +0400 Subject: [LLVMdev] regarding the high level design of GCC-LLVM In-Reply-To: <31ba424e0705210325p1c375692t46b253998459d2bc.SS393SS@mail.gmail.com> References: <31ba424e0705210325p1c375692t46b253998459d2bc.SS393SS@mail.gmail.com> Message-ID: <1179770341.5117.6.camel@asl.dorms.spbu.ru> Hello, Manish. > I want to ask how and where tree data structures are converted into > llvm data structures. gcc-to-llvm converter operates on high GIMPLE trees. All necessary logic is in llvm*.cpp files. The hooks are made in varasm.c file. -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University. From djg at cray.com Mon May 21 17:58:53 2007 From: djg at cray.com (Dan Gohman) Date: Mon, 21 May 2007 17:58:53 -0500 Subject: [LLVMdev] Simplifing the handling of pre-legalize vector nodes Message-ID: <20070521225852.GS17728@village.us.cray.com> Right now there are special SelectionDAG node kinds for operations on "abstract" vector types (VLOAD, VADD, and all the rest), and a special MVT::Vector ValueType for them. These nodes carry two additional operands, constants which specify the vector length and element type. All of this is only used before legalize; then they are replaced with regular node kinds and value types. It seems that a number of things would be considerably simpler if the pre-legalize nodes could use the same node kinds as post-legalize; the only thing preventing that is that the MVT::ValueType enum isn't able to describe vector types with arbitrarily long vector lengths. I'm currently considering ways to make this possible. One idea is to rename the MVT::ValueType enum to something else and make MVT::ValueType a plain integer type. Values beyond the range of the original enum are interpreted as indices into a UniqueVector which holds pairs of vector lengths and element types. This would require most of the ValueType utility routines to be aware of the new kinds of ValueTypes so that they could handle them properly, but once that's done, it would allow vector nodes to be handled consistently between pre-legalize and post-legalize, without obscure constructs like ... blahblah->getNumOperands()-2 ... ... *(blahblah->op_end()-1) ... to get the vector length and/or element type in the pre-legalize form. It would make -view-legalize-dags and earlier DAG drawings a lot easier to read in DAGS with vector nodes, because they wouldn't need to be edges from each vector node up to the common element type node and vector length node. Finally, and of particular interest for me, it may help with the next steps beyond PR400, as it would allow vector loads to use plain LoadSDNode nodes instead of VLOAD, and thus have an alignment, not to mention a volatile flag and alias information, in a consistent manner with regular loads. Before I do much more experimentation with this, I wanted to run the idea by the list to see what feedback it might get. Has anyone thought about doing this before? Are there other approaches that might be better? Another idea is to get rid of the ValueType concept altogether and just use Type* for everything. I don't know how this would work with various tablegen'd pieces of code though. Dan -- Dan Gohman, Cray Inc. From evan.cheng at apple.com Mon May 21 18:23:58 2007 From: evan.cheng at apple.com (Evan Cheng) Date: Mon, 21 May 2007 16:23:58 -0700 Subject: [LLVMdev] instruction writing two successive registers In-Reply-To: <46518362.4060200@mail.tuwien.ac.at> References: <46518362.4060200@mail.tuwien.ac.at> Message-ID: On May 21, 2007, at 4:32 AM, Florian Brandner wrote: > hi, > > the architecture that we are compiling for has a special vector > shuffle > instruction, which writes two successive registers (Rn and Rn+1). > > i have defined intrinsics to generate the instruction, and a special > register class for the register pairs. in addition i have two EXTRACT > operations which allow to access either the first or second > subregister > of a pair (using moves). the pair register class is used only for this > purpose and may not occur in other operations. > > this works fine. except for the extra moves generated by the EXTRACT, > which can not be eliminated by coalescing, due to the differing > register > classes. > > here is a small example: > > // Pn is a register pair > // 'a' and 'b' are regular registers > Pn = shuffle(x, y) > a = extract_lo(Pn) // which is a = Rn, > b = extract_hi(Pn) // which is b = Rn+1 > > here it would be nice to assign 'a' to the first subregister of Pn > (Rn), > and b to the second (Rn+1). > > instead of using the pair register class, i also thought about > adding a > register constraint - something like TIED_TO_NEXT. > > can anyone give me an advise how to handle this special instruction? Pair register class is the right way to handle this. Unfortunately, you won't be able to get rid of extra copies until PR1350 has been completed: http://llvm.org/bugs/show_bug.cgi?id=1350 Evan > > thank you, > florian > > > > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From emil at cs.rmit.edu.au Tue May 22 02:56:21 2007 From: emil at cs.rmit.edu.au (Emil Mikulic) Date: Tue, 22 May 2007 17:56:21 +1000 Subject: [LLVMdev] 2.0 Pre-release tarballs online In-Reply-To: References: <20070518031157.GA23323@cs.rmit.edu.au> <20070518055706.GA6875@cs.rmit.edu.au> Message-ID: <20070522075621.GA15847@cs.rmit.edu.au> On Thu, May 17, 2007 at 11:55:37PM -0700, Chris Lattner wrote: > On Fri, 18 May 2007, Emil Mikulic wrote: > > > > CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (3000.12-MHz 686-class CPU) > > Origin = "GenuineIntel" Id = 0xf34 Stepping = 4 > > Features=0xbfebfbff > MOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> > > Features2=0x441d> > > > > Looks like 1, 2, _and_ 3 are supported. > > is xTPR (Send Task Priority Messages) > > Okay, this is probably some stack alignment issue or something. Can you > please file a bug? This is not a 2.0 blocker, but we want to track it. Sure thing: http://llvm.org/bugs/show_bug.cgi?id=1438 Sorry if I got the product / category / whatever wrong. Bugzilla always confuses me. =( --Emil From nicolas.geoffray at lip6.fr Tue May 22 05:16:32 2007 From: nicolas.geoffray at lip6.fr (Nicolas Geoffray) Date: Tue, 22 May 2007 12:16:32 +0200 Subject: [LLVMdev] Compiling llvm-gcc in linux/ppc In-Reply-To: <46497FA6.8000801@lip6.fr> References: <46487930.8090102@lip6.fr> <46497FA6.8000801@lip6.fr> Message-ID: <4652C300.7010503@lip6.fr> OK, seems like there were unused TARGET_MACHO macros that would protect these errors from happening. I made some modifications that add #if TARGET_MACHO. Now the error is a linkage problem: /home/varth/project/llvm-cvs/llvm-gcc4/obj/gcc/xgcc: symbol lookup error: /home/varth/project/llvm-cvs/llvm-gcc4/obj/gcc/libgcc_s.so.1: undefined symbol: __thenan_sf And even if I force the definition of thenan_sf with const fp_number_type __thenan_sf = { CLASS_SNAN, 0, 0, {(fractype) 0} }; I still get the error. Cheers, Nicolas Nicolas Geoffray wrote: > Chris Lattner wrote: > >> This looks like you're compiling llvm-gcc3, which is quite dead by now. >> Please follow these instructions: >> http://llvm.org/docs/CFEBuildInstrs.html >> >> >> > Oups, sorry for that. Here is the error message with the latest svn version: > > gcc -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes > -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros > -Wold-style-definition -DHAVE_CONFIG_H -DENABLE_LLVM > -D__STDC_LIMIT_MACROS -I. -I. -I../../trunk/gcc -I../../trunk/gcc/. > -I../../trunk/gcc/../include -I../../trunk/gcc/../libcpp/include > -I/home/varth/project/llvm-cvs/llvm/include > -I/usr/local/home/varth/project/llvm-cvs/llvm/include > ../../trunk/gcc/stor-layout.c -o stor-layout.o > ../../trunk/gcc/stor-layout.c:450:25: error: macro "ADJUST_FIELD_ALIGN" > passed 3 arguments, but takes just 2 > ../../trunk/gcc/stor-layout.c: In function 'layout_decl': > ../../trunk/gcc/stor-layout.c:449: error: 'ADJUST_FIELD_ALIGN' > undeclared (first use in this function) > ../../trunk/gcc/stor-layout.c:449: error: (Each undeclared identifier is > reported only once > ../../trunk/gcc/stor-layout.c:449: error: for each function it appears in.) > ../../trunk/gcc/stor-layout.c:711:43: error: macro "ADJUST_FIELD_ALIGN" > passed 3 arguments, but takes just 2 > ../../trunk/gcc/stor-layout.c: In function 'update_alignment_for_field': > ../../trunk/gcc/stor-layout.c:708: error: 'ADJUST_FIELD_ALIGN' > undeclared (first use in this function) > ../../trunk/gcc/stor-layout.c:760:41: error: macro "ADJUST_FIELD_ALIGN" > passed 3 arguments, but takes just 2 > ../../trunk/gcc/stor-layout.c:994:44: error: macro "ADJUST_FIELD_ALIGN" > passed 3 arguments, but takes just 2 > ../../trunk/gcc/stor-layout.c: In function 'place_field': > ../../trunk/gcc/stor-layout.c:991: error: 'ADJUST_FIELD_ALIGN' > undeclared (first use in this function) > ../../trunk/gcc/stor-layout.c:1031:44: error: macro "ADJUST_FIELD_ALIGN" > passed 3 arguments, but takes just 2 > make[1]: *** [stor-layout.o] Error 1 > make[1]: Leaving directory `/home/varth/project/llvm-cvs/llvm-gcc4/obj/gcc' > make: *** [all-gcc] Error 2 > > > I looked a bit at the source, and the gcc/config/darwin.h declares a > ADJUST_FIELD_ALIGN with two arguments whereas all other back-ends that > declare ADJUST_FIELD_ALIGN have only two arguments. And it seems that > stor-layout.c assumes that if we have ADJUST_FIELD_ALIGN defined, then > we're on darwin. > > Nicolas > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From tonic at nondot.org Tue May 22 13:16:21 2007 From: tonic at nondot.org (Tanya M. Lattner) Date: Tue, 22 May 2007 11:16:21 -0700 (PDT) Subject: [LLVMdev] Updated: 2.0 Pre-release tarballs online In-Reply-To: References: Message-ID: Just a reminder, if anyone is still testing, please send me your results by 5pm PDT Today! At this point, it looks like the release is on schedule for Wednesday. We won't be delaying it unless new test results reveal major problems. Thanks for all your help, Tanya On Fri, 18 May 2007, Tanya M. Lattner wrote: > > I've updated the pre-release tarballs online. I'm also extending the testing > completion date to May 22nd at 5pm PDT. The new release target date is May > 23rd. > > If you have any free time, please give the new pre-release a try. > > Thanks to all who have tested LLVM! > > -Tanya > > P.S. Documentation review should still be completed today! Thanks! > > >> I've uploaded the 2.0 pre-release to this location: >> http://llvm.org/prereleases/2.0/ >> >> If you have free time and would like to help test this release, please >> download the appropriate tarballs from the website. >> >> Here are a few ways you can help test this release: >> >> 1) Download llvm-gcc4 binary and llvm. Compile and run make check. >> >> 2) Download llvm-gcc4 binary, llvm, and llvm-test. Compile, run make >> check, and do "make ENABLE_OPTIMIZED=1 TEST=nightly report" in llvm-test. >> >> 3) Compile llvm-gcc4 and llvm from source. Run 'make check'. >> >> 4) Compile llvm-gcc4 and llvm from source. Run 'make check' and do a 'make >> ENABLE_OPTIMIZED=1 TEST=nightly report' in llvm-test. >> >> It would also be helpful for someone to compile/test with objdir != >> srcdir. >> The 2.0 release defaults to a Release build, but you are welcome to test >> with a Debug build as well. >> >> When reporting your results, please email the list and mention what >> platform, which option you chose (1, 2, 3, or 4), and if you made any >> configure changes (objdir != srcdir, or Debug build). Include the dejagnu >> test log or the nightly test report. >> >> Thanks, >> Tanya Lattner >> >> > From bjchambers at gmail.com Tue May 22 20:51:42 2007 From: bjchambers at gmail.com (Ben Chambers) Date: Tue, 22 May 2007 21:51:42 -0400 Subject: [LLVMdev] LLVM GCC and Malloc Message-ID: I've noticed a slight difference between the code emitted by LLVM-GCC and what the online demo emits. For instance, the C code: malloc (5 * sizeof(int)) becomes malloc [5 x int] when using the online demo, and call @malloc (i32 20) when using llvm-gcc. I understand that the effective behavior is the same thing, but for some work that I'm doing it's much better to have the malloc [5 x int], because it is more detailed. Is there some way to get llvm-gcc to emit this information, or an optimization pass I can run to recover this more detailed information? Thanks, Ben Chambers From sabre at nondot.org Wed May 23 00:19:09 2007 From: sabre at nondot.org (Chris Lattner) Date: Tue, 22 May 2007 22:19:09 -0700 (PDT) Subject: [LLVMdev] LLVM GCC and Malloc In-Reply-To: References: Message-ID: On Tue, 22 May 2007, Ben Chambers wrote: > I've noticed a slight difference between the code emitted by LLVM-GCC > and what the online demo emits. For instance, the C code: The primary reason for this is that the demo page is running LLVM 1.9, where mainline more closely resembles LLVM 2.0. When 2.0 is done (real soon now) we'll switch it over. > malloc (5 * sizeof(int)) > becomes > malloc [5 x int] > when using the online demo, and > call @malloc (i32 20) > when using llvm-gcc. > > I understand that the effective behavior is the same thing, but for > some work that I'm doing it's much better to have the malloc [5 x > int], because it is more detailed. Is there some way to get llvm-gcc > to emit this information, or an optimization pass I can run to recover > this more detailed information? Are you passing -O3 to llvm-gcc? This could be a case where the raiseallocs pass is missing turning the malloc call into a malloc instruction. If -O3 doesn't help, please file a bugzilla and we can fix it. Thanks! -Chris -- http://nondot.org/sabre/ http://llvm.org/ From sabre at nondot.org Wed May 23 01:52:46 2007 From: sabre at nondot.org (Chris Lattner) Date: Tue, 22 May 2007 23:52:46 -0700 (PDT) Subject: [LLVMdev] API changes (was Antw.: 2.0 Pre-release tarballs online) In-Reply-To: References: <0618F80F-6E10-4817-9C2E-6CBA63877F81.SS1239SS@ugent.be> <1179524140.28365.14.camel@asl.dorms.spbu.ru> Message-ID: On Sun, 20 May 2007, Bram Adams wrote: > Op 19-mei-07, om 00:39 heeft Chris Lattner het volgende geschreven: >> Anton is right. You should be able to use -fno-builtins to disable >> this. > > Thanks, that did the trick. > > Some final remarks (my app works again :-)): > * llvm.va_start and similar intrinsics now have an i8* arg instead > of an sbyte** ok > * For some reason the Arguments of a Function are now circularly > linked, i.e. getPrev()/Next() does not yield 0 when the first > Argument is reached, but jumps back to the last one. I experienced > this with a loop I was using to find out the index of an Argument. It > relied on the fact that getPrev() would eventually give 0, which > worked in previous LLVM versions. Ah, these should be private. Thanks for pointing this out, I'll fix ;-). You should use iterators. > On a related note: while using llvmc I have some test cases where the > following error now pops up on Linux X86 (not on OSX): > > : CommandLine Error: Argument 'debug' defined more than once! > llvmc: CommandLine Error: Argument 'debug' defined more than once! No idea. :) llvmc is a work in progress which has stagnated somewhat. I strongly recommend using llvm-gcc directly. -Chris -- http://nondot.org/sabre/ http://llvm.org/ From sabre at nondot.org Wed May 23 02:03:30 2007 From: sabre at nondot.org (Chris Lattner) Date: Wed, 23 May 2007 00:03:30 -0700 (PDT) Subject: [LLVMdev] Simplifing the handling of pre-legalize vector nodes In-Reply-To: <20070521225852.GS17728@village.us.cray.com> References: <20070521225852.GS17728@village.us.cray.com> Message-ID: Sorry for the delay, things are more insane than usual, with the pending release, the dev mtg, etc :) On Mon, 21 May 2007, Dan Gohman wrote: > Right now there are special SelectionDAG node kinds for operations on > "abstract" vector types (VLOAD, VADD, and all the rest), and a special > MVT::Vector ValueType for them. These nodes carry two additional operands, > constants which specify the vector length and element type. All of this is > only used before legalize; then they are replaced with regular node kinds > and value types. Right. > It seems that a number of things would be considerably simpler if the > pre-legalize nodes could use the same node kinds as post-legalize; the only > thing preventing that is that the MVT::ValueType enum isn't able to describe > vector types with arbitrarily long vector lengths. Yep, I'm sure you know this, but this is to support generic vectors. For example, if you had an input .ll that operated on 128-wide vectors, we want to be able to split that up to use 4-wide vectors if your target supports them. Going forward, we will also likely have to do something similar to this for integer types, in order to handle stuff like i47 that gets legalized into 2 x i32 or something. I am not looking forward to duplicating all of the arithmetic nodes for IADD variants etc (urk, imagine vectors of strange-sized-integers! VIADD??) > I'm currently considering ways to make this possible. One idea is to rename > the MVT::ValueType enum to something else and make MVT::ValueType a plain > integer type. Values beyond the range of the original enum are interpreted > as indices into a UniqueVector which holds pairs of vector lengths and > element types. That is a very interesting idea. It handles the generality of arbitrary value types, but is nice and fast for the common code that doesn't use the craziness :). I like it! > This would require most of the ValueType utility routines > to be aware of the new kinds of ValueTypes so that they could handle them > properly, but once that's done, it would allow vector nodes to be handled > consistently between pre-legalize and post-legalize, without obscure > constructs like > ... blahblah->getNumOperands()-2 ... > ... *(blahblah->op_end()-1) ... > to get the vector length and/or element type in the pre-legalize form. That would be amazingly wonderful. The other nice thing about this is that 'normal' code that uses (e.g.) sse intrinsics wouldn't have to have all the nodes rewritten multiple times from VADD->ADD->... Anything in a legal type would just be created and stay legal. > It would make -view-legalize-dags and earlier DAG drawings a lot easier to > read in DAGS with vector nodes, because they wouldn't need to be edges from > each vector node up to the common element type node and vector length node. Also true. > Finally, and of particular interest for me, it may help with the next steps > beyond PR400, as it would allow vector loads to use plain LoadSDNode nodes > instead of VLOAD, and thus have an alignment, not to mention a volatile flag > and alias information, in a consistent manner with regular loads. Yep. For this specific one, it would be possible to enhance vload, but I agree that this is not a very appealing solution :) > Before I do much more experimentation with this, I wanted to run the idea by > the list to see what feedback it might get. Has anyone thought about doing > this before? Are there other approaches that might be better? This approach sounds very sensible. Make sure the SelectionDAG owns the table though. > Another idea is to get rid of the ValueType concept altogether and just use > Type* for everything. I don't know how this would work with various > tablegen'd pieces of code though. I'd suggest sticking with ValueTypes. Among other things, they can be indexed into arrays and Type*'s can't. This is important for the various tables in targetlowering that the legalizer consults to find out if a type/operation is valid. -Chris -- http://nondot.org/sabre/ http://llvm.org/ From rspencer at reidspencer.com Wed May 23 00:47:41 2007 From: rspencer at reidspencer.com (Reid Spencer) Date: Wed, 23 May 2007 01:47:41 -0400 Subject: [LLVMdev] API changes (was Antw.: 2.0 Pre-release tarballs online) In-Reply-To: References: <0618F80F-6E10-4817-9C2E-6CBA63877F81.SS1239SS@ugent.be> <1179524140.28365.14.camel@asl.dorms.spbu.ru> Message-ID: On Tue, 22 May 2007 23:52:46 -0700 (PDT) Chris Lattner wrote: >On Sun, 20 May 2007, Bram Adams wrote: >> On a related note: while using llvmc I have some test cases where the >> following error now pops up on Linux X86 (not on OSX): >> >> : CommandLine Error: Argument 'debug' defined more than once! >> llvmc: CommandLine Error: Argument 'debug' defined more than once! > >No idea. :) > >llvmc is a work in progress which has stagnated somewhat. I strongly >recommend using llvm-gcc directly. Bram: About the only way I know of to get that error is if you linked LLVM into a loadable module and loaded it with llvmc. Did you do that? If so, don't link any LLVM stuff into your module! See the Makefile in the "Hello" transform for an example of how to do this. If you need to use something in LLVM that is not linked into llvmc (so it can't be dynamically resolved at load time), then either a) find another way to do it (without using LLVM) or b) copy the code and link it statically into your loadable module making sure that you remove any static constructors/destructors for pass registration, statistics or command line options. Reid. > >-Chris > >-- >http://nondot.org/sabre/ >http://llvm.org/ >_______________________________________________ >LLVM Developers mailing list >LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From sabre at nondot.org Wed May 23 02:16:40 2007 From: sabre at nondot.org (Chris Lattner) Date: Wed, 23 May 2007 00:16:40 -0700 (PDT) Subject: [LLVMdev] llvm, gpu execution environments In-Reply-To: <464EADE5.300@tungstengraphics.com> References: <464D7E9C.7080608@tungstengraphics.com> <464EADE5.300@tungstengraphics.com> Message-ID: On Sat, 19 May 2007, Keith Whitwell wrote: >>> It seems that LLVA and by extension Vector-LLVA assumes that looping and >>> branching control flow can be expressed in terms of a simple "br" branch >>> operation. >> >> LLVA is not a part of LLVM, so I won't answer for it. > > OK, I guess I misunderstood the papers I pulled down - my impression was > that at some stage programs in llvm would be represented in LLVA. > > What, out of interest, is the relationship between LLVM and LLVA? Vikram already answered this, but LLVA is a research project that uses LLVM. LLVM does already have vector support in place. >> Basically, you want to model this as predicated execution, and you want >> the code generator to predicate away as many branches etc as possible. >> >> One observation can be made though: there will always be some programs >> that you can't map onto the hardware. For example, if you don't have >> branches, you can't do loops that execute for a variable number of >> iterations. > > Actually, you can - there is a program counter, the loop keeps executing > until the execution mask reaches zero. Likewise branches are dynamic. Ok, but can you supports 4 level deep loops with arbitrary indexed loads in them? >> As such, I'd structure the compiler as a typical code generator with an >> early predication pass that flattens branches. If you get to the end of >> the codegen and have some dynamic branches left, you detect the error >> condition and reject the shader from the hardware path (so you have to >> emulate it in software). > > The hardware *does* support dynamic branching, and looping, provided it > is expressed in IF/THEN/ELSE, LOOP/BREAK/CONTINUE/ENDLOOP type > instructions. Even CALL/RETURN. The only thing it can't do is execute > something like "GOTO" or "BRANCH" dynamically. Ahh, ok. Very interesting. >> Does this make sense? > > Yes, but at slight cross-purposes. > > There are no cases where compilation should fail to produce a hardware > executable result, within the constraints of the high-level language we > are compiling. Dynamic branches and looping are entirely within the > capability of the hardware, provided they are expressed in terms of the > hardware IF/THEN/ELSE, LOOP/ENDLOOP, etc, opcodes. Okay. > But it seems like my initial understanding of the intermediate > representation within llvm is incorrect & I probably should just dive > into the source to figure out what's going on. Always good :) > My concern was that llva throws away the information that I'd probably > need to reconstruct these high-level opcodes required by the hardware - > if the code generator can come in at a higher level while that > information still exists, then a lot of things get easier. s/llva/llvm/ But yes, you're right. Reconstructing loops etc from LLVM is actually really easy, but we don't have good support for it in the code generator yet. This is a desired area of extension that we'd like to do at some point, see http://llvm.org/PR1353 -Chris -- http://nondot.org/sabre/ http://llvm.org/ From sabre at nondot.org Wed May 23 02:18:51 2007 From: sabre at nondot.org (Chris Lattner) Date: Wed, 23 May 2007 00:18:51 -0700 (PDT) Subject: [LLVMdev] Compiling llvm-gcc in linux/ppc In-Reply-To: <4652C300.7010503@lip6.fr> References: <46487930.8090102@lip6.fr> <46497FA6.8000801@lip6.fr> <4652C300.7010503@lip6.fr> Message-ID: On Tue, 22 May 2007, Nicolas Geoffray wrote: > OK, seems like there were unused TARGET_MACHO macros that would protect > these errors from happening. I made some modifications that add #if > TARGET_MACHO. ok. If you send a patch in that adds these, I would be happy to apply it. > Now the error is a linkage problem: > > /home/varth/project/llvm-cvs/llvm-gcc4/obj/gcc/xgcc: symbol lookup > error: /home/varth/project/llvm-cvs/llvm-gcc4/obj/gcc/libgcc_s.so.1: > undefined symbol: __thenan_sf > > And even if I force the definition of thenan_sf with > const fp_number_type __thenan_sf = { CLASS_SNAN, 0, 0, {(fractype) 0} }; > > I still get the error. Unfortunately, I really don't know. I assume this is supposed to be coming from gcc/config/fp-bit.c, but I don't know how any of this stuff works. -Chris > Cheers, > Nicolas > > Nicolas Geoffray wrote: >> Chris Lattner wrote: >> >>> This looks like you're compiling llvm-gcc3, which is quite dead by now. >>> Please follow these instructions: >>> http://llvm.org/docs/CFEBuildInstrs.html >>> >>> >>> >> Oups, sorry for that. Here is the error message with the latest svn version: >> >> gcc -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes >> -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros >> -Wold-style-definition -DHAVE_CONFIG_H -DENABLE_LLVM >> -D__STDC_LIMIT_MACROS -I. -I. -I../../trunk/gcc -I../../trunk/gcc/. >> -I../../trunk/gcc/../include -I../../trunk/gcc/../libcpp/include >> -I/home/varth/project/llvm-cvs/llvm/include >> -I/usr/local/home/varth/project/llvm-cvs/llvm/include >> ../../trunk/gcc/stor-layout.c -o stor-layout.o >> ../../trunk/gcc/stor-layout.c:450:25: error: macro "ADJUST_FIELD_ALIGN" >> passed 3 arguments, but takes just 2 >> ../../trunk/gcc/stor-layout.c: In function 'layout_decl': >> ../../trunk/gcc/stor-layout.c:449: error: 'ADJUST_FIELD_ALIGN' >> undeclared (first use in this function) >> ../../trunk/gcc/stor-layout.c:449: error: (Each undeclared identifier is >> reported only once >> ../../trunk/gcc/stor-layout.c:449: error: for each function it appears in.) >> ../../trunk/gcc/stor-layout.c:711:43: error: macro "ADJUST_FIELD_ALIGN" >> passed 3 arguments, but takes just 2 >> ../../trunk/gcc/stor-layout.c: In function 'update_alignment_for_field': >> ../../trunk/gcc/stor-layout.c:708: error: 'ADJUST_FIELD_ALIGN' >> undeclared (first use in this function) >> ../../trunk/gcc/stor-layout.c:760:41: error: macro "ADJUST_FIELD_ALIGN" >> passed 3 arguments, but takes just 2 >> ../../trunk/gcc/stor-layout.c:994:44: error: macro "ADJUST_FIELD_ALIGN" >> passed 3 arguments, but takes just 2 >> ../../trunk/gcc/stor-layout.c: In function 'place_field': >> ../../trunk/gcc/stor-layout.c:991: error: 'ADJUST_FIELD_ALIGN' >> undeclared (first use in this function) >> ../../trunk/gcc/stor-layout.c:1031:44: error: macro "ADJUST_FIELD_ALIGN" >> passed 3 arguments, but takes just 2 >> make[1]: *** [stor-layout.o] Error 1 >> make[1]: Leaving directory `/home/varth/project/llvm-cvs/llvm-gcc4/obj/gcc' >> make: *** [all-gcc] Error 2 >> >> >> I looked a bit at the source, and the gcc/config/darwin.h declares a >> ADJUST_FIELD_ALIGN with two arguments whereas all other back-ends that >> declare ADJUST_FIELD_ALIGN have only two arguments. And it seems that >> stor-layout.c assumes that if we have ADJUST_FIELD_ALIGN defined, then >> we're on darwin. >> >> Nicolas >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > -Chris -- http://nondot.org/sabre/ http://llvm.org/ From sabre at nondot.org Wed May 23 02:23:38 2007 From: sabre at nondot.org (Chris Lattner) Date: Wed, 23 May 2007 00:23:38 -0700 (PDT) Subject: [LLVMdev] alias information on machine instructions In-Reply-To: <463AEEDD.3000106@mail.tuwien.ac.at> References: <4635D0D4.40202@mail.tuwien.ac.at> <463AEEDD.3000106@mail.tuwien.ac.at> Message-ID: On Fri, 4 May 2007, Florian Brandner wrote: > Chris Lattner wrote: >> There are a couple of ways to do this. Is your scheduler a prepass >> scheduler (before regalloc) or a post-pass scheduler (after regalloc)? > > it is a post-pass scheduler, which operates on MachineInstrs. we need to > run it after register allocation to hide latencies of spill code, > prolog, and epilog. ok. >> If you want to extract maximal parallelism, I assume you want a prepass >> scheduler. In that case, you should look into the SelectionDAG based >> schedulers, which do have alias information on them. > > i had a look at the SelectionDAG based schedulers. it seems that > aliasing loads/stores are chained together by the DAGCombiner. after > scheduling, when the MachineInstrs are created, the alias information > cannot be used anymore in the current framework. is this correct? Right. The original Value*'s are preserved in the DAG, but dropped when MachineInstrs are created. We could add a machineoperand to capture this Value* if desired. > i don't think that it is a good idea to do alias analysis on > MachineInstrs, thus i would like to preserve the alias information, and > annotate the MachineInstrs explicitly. however, this information might > be invalidated by subsequent passes. Right, it would have to be added as a Value* operand to MachineInstr. This would not be invalidated by later passes, they would just ignore the field. Targets would have to be updated though, as certain pieces of code "know" about the expected operands. -Chris -- http://nondot.org/sabre/ http://llvm.org/ From nicolas.geoffray at lip6.fr Wed May 23 02:33:34 2007 From: nicolas.geoffray at lip6.fr (Nicolas Geoffray) Date: Wed, 23 May 2007 09:33:34 +0200 Subject: [LLVMdev] Compiling llvm-gcc in linux/ppc In-Reply-To: References: <46487930.8090102@lip6.fr> <46497FA6.8000801@lip6.fr> <4652C300.7010503@lip6.fr> Message-ID: <4653EE4E.2060606@lip6.fr> Hi Chris, Chris Lattner wrote: > On Tue, 22 May 2007, Nicolas Geoffray wrote: > >> OK, seems like there were unused TARGET_MACHO macros that would protect >> these errors from happening. I made some modifications that add #if >> TARGET_MACHO. >> > > ok. If you send a patch in that adds these, I would be happy to apply it. > > I will when I'll figure out why it sometimes doesn't work to add these and I have to remove the specific instructions from the file (even an #if 0 does not work -- maybe there's a script somewhere that misbehaves) >> Now the error is a linkage problem: >> >> /home/varth/project/llvm-cvs/llvm-gcc4/obj/gcc/xgcc: symbol lookup >> error: /home/varth/project/llvm-cvs/llvm-gcc4/obj/gcc/libgcc_s.so.1: >> undefined symbol: __thenan_sf >> >> And even if I force the definition of thenan_sf with >> const fp_number_type __thenan_sf = { CLASS_SNAN, 0, 0, {(fractype) 0} }; >> >> I still get the error. >> > > Unfortunately, I really don't know. I assume this is supposed to be > coming from gcc/config/fp-bit.c, but I don't know how any of this stuff > works. > > Do you know who did the APPLE_LOCAL changes? Maybe he can help. Nicolas > -Chris > > > >> Cheers, >> Nicolas >> >> Nicolas Geoffray wrote: >> >>> Chris Lattner wrote: >>> >>> >>>> This looks like you're compiling llvm-gcc3, which is quite dead by now. >>>> Please follow these instructions: >>>> http://llvm.org/docs/CFEBuildInstrs.html >>>> >>>> >>>> >>>> >>> Oups, sorry for that. Here is the error message with the latest svn version: >>> >>> gcc -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes >>> -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros >>> -Wold-style-definition -DHAVE_CONFIG_H -DENABLE_LLVM >>> -D__STDC_LIMIT_MACROS -I. -I. -I../../trunk/gcc -I../../trunk/gcc/. >>> -I../../trunk/gcc/../include -I../../trunk/gcc/../libcpp/include >>> -I/home/varth/project/llvm-cvs/llvm/include >>> -I/usr/local/home/varth/project/llvm-cvs/llvm/include >>> ../../trunk/gcc/stor-layout.c -o stor-layout.o >>> ../../trunk/gcc/stor-layout.c:450:25: error: macro "ADJUST_FIELD_ALIGN" >>> passed 3 arguments, but takes just 2 >>> ../../trunk/gcc/stor-layout.c: In function 'layout_decl': >>> ../../trunk/gcc/stor-layout.c:449: error: 'ADJUST_FIELD_ALIGN' >>> undeclared (first use in this function) >>> ../../trunk/gcc/stor-layout.c:449: error: (Each undeclared identifier is >>> reported only once >>> ../../trunk/gcc/stor-layout.c:449: error: for each function it appears in.) >>> ../../trunk/gcc/stor-layout.c:711:43: error: macro "ADJUST_FIELD_ALIGN" >>> passed 3 arguments, but takes just 2 >>> ../../trunk/gcc/stor-layout.c: In function 'update_alignment_for_field': >>> ../../trunk/gcc/stor-layout.c:708: error: 'ADJUST_FIELD_ALIGN' >>> undeclared (first use in this function) >>> ../../trunk/gcc/stor-layout.c:760:41: error: macro "ADJUST_FIELD_ALIGN" >>> passed 3 arguments, but takes just 2 >>> ../../trunk/gcc/stor-layout.c:994:44: error: macro "ADJUST_FIELD_ALIGN" >>> passed 3 arguments, but takes just 2 >>> ../../trunk/gcc/stor-layout.c: In function 'place_field': >>> ../../trunk/gcc/stor-layout.c:991: error: 'ADJUST_FIELD_ALIGN' >>> undeclared (first use in this function) >>> ../../trunk/gcc/stor-layout.c:1031:44: error: macro "ADJUST_FIELD_ALIGN" >>> passed 3 arguments, but takes just 2 >>> make[1]: *** [stor-layout.o] Error 1 >>> make[1]: Leaving directory `/home/varth/project/llvm-cvs/llvm-gcc4/obj/gcc' >>> make: *** [all-gcc] Error 2 >>> >>> >>> I looked a bit at the source, and the gcc/config/darwin.h declares a >>> ADJUST_FIELD_ALIGN with two arguments whereas all other back-ends that >>> declare ADJUST_FIELD_ALIGN have only two arguments. And it seems that >>> stor-layout.c assumes that if we have ADJUST_FIELD_ALIGN defined, then >>> we're on darwin. >>> >>> Nicolas >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>> >>> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> > > -Chris > > From sabre at nondot.org Wed May 23 04:00:07 2007 From: sabre at nondot.org (Chris Lattner) Date: Wed, 23 May 2007 02:00:07 -0700 (PDT) Subject: [LLVMdev] Compiling llvm-gcc in linux/ppc In-Reply-To: <4653EE4E.2060606@lip6.fr> References: <46487930.8090102@lip6.fr> <46497FA6.8000801@lip6.fr> <4652C300.7010503@lip6.fr> <4653EE4E.2060606@lip6.fr> Message-ID: On Wed, 23 May 2007, Nicolas Geoffray wrote: > I will when I'll figure out why it sometimes doesn't work to add these > and I have to remove the specific instructions from the file (even an > #if 0 does not work -- maybe there's a script somewhere that misbehaves) Ok. >> Unfortunately, I really don't know. I assume this is supposed to be >> coming from gcc/config/fp-bit.c, but I don't know how any of this stuff >> works. > Do you know who did the APPLE_LOCAL changes? Maybe he can help. If you point out a specific file/line# that is causing you grief, I can try to find out :) -Chris -- http://nondot.org/sabre/ http://llvm.org/ From keith at tungstengraphics.com Wed May 23 02:58:11 2007 From: keith at tungstengraphics.com (Keith Whitwell) Date: Wed, 23 May 2007 08:58:11 +0100 Subject: [LLVMdev] llvm, gpu execution environments In-Reply-To: References: <464D7E9C.7080608@tungstengraphics.com> <464EADE5.300@tungstengraphics.com> Message-ID: <4653F413.7080203@tungstengraphics.com> Chris Lattner wrote: > On Sat, 19 May 2007, Keith Whitwell wrote: >>>> It seems that LLVA and by extension Vector-LLVA assumes that looping and >>>> branching control flow can be expressed in terms of a simple "br" branch >>>> operation. >>> LLVA is not a part of LLVM, so I won't answer for it. >> OK, I guess I misunderstood the papers I pulled down - my impression was >> that at some stage programs in llvm would be represented in LLVA. >> >> What, out of interest, is the relationship between LLVM and LLVA? > > Vikram already answered this, but LLVA is a research project that uses > LLVM. LLVM does already have vector support in place. > >>> Basically, you want to model this as predicated execution, and you want >>> the code generator to predicate away as many branches etc as possible. >>> >>> One observation can be made though: there will always be some programs >>> that you can't map onto the hardware. For example, if you don't have >>> branches, you can't do loops that execute for a variable number of >>> iterations. >> Actually, you can - there is a program counter, the loop keeps executing >> until the execution mask reaches zero. Likewise branches are dynamic. > > Ok, but can you supports 4 level deep loops with arbitrary indexed loads > in them? Yes, absolutely. There may be limits to the depth of the stacks that underly the predication mechanism, and there may be special actions required to be taken when those stacks are exhausted, but this type of detail varies from GPU to GPU. The hardware we have access to (Intel i965) just needs some hand-holding when the predication stacks max out. Some GPUs may use an entirely different internal architecture and implementation details like stacks and predication may not apply. But the evidence from benchmarks of dynamic branching behaviour, etc, on those GPUs suggests things must be pretty similar. >>> As such, I'd structure the compiler as a typical code generator with an >>> early predication pass that flattens branches. If you get to the end of >>> the codegen and have some dynamic branches left, you detect the error >>> condition and reject the shader from the hardware path (so you have to >>> emulate it in software). >> The hardware *does* support dynamic branching, and looping, provided it >> is expressed in IF/THEN/ELSE, LOOP/BREAK/CONTINUE/ENDLOOP type >> instructions. Even CALL/RETURN. The only thing it can't do is execute >> something like "GOTO" or "BRANCH" dynamically. > > Ahh, ok. Very interesting. > >>> Does this make sense? >> Yes, but at slight cross-purposes. >> >> There are no cases where compilation should fail to produce a hardware >> executable result, within the constraints of the high-level language we >> are compiling. Dynamic branches and looping are entirely within the >> capability of the hardware, provided they are expressed in terms of the >> hardware IF/THEN/ELSE, LOOP/ENDLOOP, etc, opcodes. > > Okay. > >> But it seems like my initial understanding of the intermediate >> representation within llvm is incorrect & I probably should just dive >> into the source to figure out what's going on. > > Always good :) > >> My concern was that llva throws away the information that I'd probably >> need to reconstruct these high-level opcodes required by the hardware - >> if the code generator can come in at a higher level while that >> information still exists, then a lot of things get easier. > > s/llva/llvm/ But yes, you're right. Reconstructing loops etc from LLVM > is actually really easy, but we don't have good support for it in the code > generator yet. This is a desired area of extension that we'd like to do > at some point, see http://llvm.org/PR1353 OK, I'll take a look. Thanks, Keith From nicolas.geoffray at lip6.fr Wed May 23 04:04:40 2007 From: nicolas.geoffray at lip6.fr (Nicolas Geoffray) Date: Wed, 23 May 2007 11:04:40 +0200 Subject: [LLVMdev] Compiling llvm-gcc in linux/ppc In-Reply-To: References: <46487930.8090102@lip6.fr> <46497FA6.8000801@lip6.fr> <4652C300.7010503@lip6.fr> <4653EE4E.2060606@lip6.fr> Message-ID: <465403A8.10300@lip6.fr> Chris Lattner wrote: >> Do you know who did the APPLE_LOCAL changes? Maybe he can help. >> > > If you point out a specific file/line# that is causing you grief, I can > try to find out :) > > Hard to tell. I think it has something to do with fp-bit.c (or its generated equivalent) dp-bit.c not being compiled or linked with xgcc (I forced the definition of thenan_sf in the fp-bit.c file). So I figure it's a Makefile somewhere that must misbehave. > -Chris > > From bram.adams at ugent.be Wed May 23 04:40:03 2007 From: bram.adams at ugent.be (Bram Adams) Date: Wed, 23 May 2007 11:40:03 +0200 Subject: [LLVMdev] API changes (was Antw.: 2.0 Pre-release tarballs online) In-Reply-To: References: <0618F80F-6E10-4817-9C2E-6CBA63877F81.SS1239SS@ugent.be> <1179524140.28365.14.camel@asl.dorms.spbu.ru> Message-ID: Hi, Op 23-mei-07, om 07:47 heeft Reid Spencer het volgende geschreven: >>> : CommandLine Error: Argument 'debug' defined more than >>> once! >>> llvmc: CommandLine Error: Argument 'debug' defined more than once! >> >> llvmc is a work in progress which has stagnated somewhat. I strongly >> recommend using llvm-gcc directly. That's my intention as soon as LTO works in the linker :-). I tried to download Chandler's patches following the links on http:// www.nabble.com/LLVM's-Link-Time-Optimizer-integrated-into-GNU-ld- t2935174.html, but his server is apparently down. Is there some mirror? > About the only way I know of to get that error is if you linked > LLVM into a loadable module and loaded it with llvmc. Did you do that? I did link a few files from the lib/Transforms/Utils-directory. When I remove them from my build my app still works (linking them with my build apparently is superfluous in 2.0), but the error still remains. However, I noticed the above messages also in the logs of the tests that succeeded, so this llvmc problem is apparently not the cause of the errors I experience. This is the command I use: llvmc --config-dir ${ASPICERE2_SRC}/config/ -Tlnk="-L${LLVM_FRONT}/ lib" -Tlnk="-L${ASPICERE2_INSTALL}/lib" -Tlnk="-L${SWI_LIB}" -Tlnk="- load=${ASPICERE2_INSTALL}/lib/weaver" -Tlnk="-load=$ {ASPICERE2_INSTALL}/lib/native" -Tlnk="-disable-opt" -Tlnk="- constmerge" -Tlnk="-globalsmodref-aa" -Tlnk="-reify" -Tlnk="-match" - Tlnk="-weave" -Tlnk="-globalsmodref-aa" -Tlnk="-internalize" -Tlnk="- ipsccp" -Tlnk="-globalopt" -Tlnk="-constmerge" -Tlnk="-deadargelim" - Tlnk="-instcombine" -Tlnk="-inline" -Tlnk="-prune-eh" -Tlnk="- globalopt" -Tlnk="-globaldce" -Tlnk="-argpromotion" -Tlnk="- instcombine" -Tlnk="-scalarrepl" -Tlnk="-globalsmodref-aa" -Tlnk="- licm" -Tlnk="-load-vn" -Tlnk="-gcse" -Tlnk="-dse" -Tlnk="- instcombine" -Tlnk="-simplifycfg" -Tlnk="-globaldce" $FILTERED_ARGS $ASPECT_STRING_TO_C There are two dynamic modules of mine which are explicitly loaded (they no longer use LLVM modules). Afterwards, some optimisation passes are listed, some more than once. However, even if I remove the optimisations the messages still appear (without harming anyone). Kind regards, Bram Adams GH-SEL, INTEC, Ghent University (Belgium) From djg at cray.com Wed May 23 09:54:29 2007 From: djg at cray.com (Dan Gohman) Date: Wed, 23 May 2007 09:54:29 -0500 Subject: [LLVMdev] alias information on machine instructions In-Reply-To: References: <4635D0D4.40202@mail.tuwien.ac.at> <463AEEDD.3000106@mail.tuwien.ac.at> Message-ID: <20070523145429.GB2502@village.us.cray.com> On Wed, May 23, 2007 at 12:23:38AM -0700, Chris Lattner wrote: > On Fri, 4 May 2007, Florian Brandner wrote: > > i had a look at the SelectionDAG based schedulers. it seems that > > aliasing loads/stores are chained together by the DAGCombiner. after > > scheduling, when the MachineInstrs are created, the alias information > > cannot be used anymore in the current framework. is this correct? > > Right. The original Value*'s are preserved in the DAG, but dropped when > MachineInstrs are created. We could add a machineoperand to capture this > Value* if desired. Another benefit of keeping the original Value*'s (and offsets) around is it would provide more information that could be used for verbose asm output and MachineInstr-level dumps, which would be quite nice. Dan -- Dan Gohman, Cray Inc. From fbrandne at mail.tuwien.ac.at Thu May 24 02:09:56 2007 From: fbrandne at mail.tuwien.ac.at (Florian Brandner) Date: Thu, 24 May 2007 09:09:56 +0200 Subject: [LLVMdev] alias information on machine instructions In-Reply-To: <20070523145429.GB2502@village.us.cray.com> References: <4635D0D4.40202@mail.tuwien.ac.at> <463AEEDD.3000106@mail.tuwien.ac.at> <20070523145429.GB2502@village.us.cray.com> Message-ID: <46553A44.4070503@mail.tuwien.ac.at> Dan Gohman wrote: > On Wed, May 23, 2007 at 12:23:38AM -0700, Chris Lattner wrote: >> On Fri, 4 May 2007, Florian Brandner wrote: >>> i had a look at the SelectionDAG based schedulers. it seems that >>> aliasing loads/stores are chained together by the DAGCombiner. after >>> scheduling, when the MachineInstrs are created, the alias information >>> cannot be used anymore in the current framework. is this correct? >> Right. The original Value*'s are preserved in the DAG, but dropped when >> MachineInstrs are created. We could add a machineoperand to capture this >> Value* if desired. > > Another benefit of keeping the original Value*'s (and offsets) around is it > would provide more information that could be used for verbose asm output > and MachineInstr-level dumps, which would be quite nice. > i'll do this and post a patch, unless someone else is already working on this. florian From bram.adams at ugent.be Thu May 24 06:51:18 2007 From: bram.adams at ugent.be (Bram Adams) Date: Thu, 24 May 2007 13:51:18 +0200 Subject: [LLVMdev] 2.0 frontend hangs Message-ID: <8F087F72-9BBE-4F3D-9FC8-A11729AD68D0@ugent.be> Hi, While trying to compile ioquake3 (http://ioquake3.org/? page=get&method=source; use provided make-macosx-ub.sh wrapper to compile) with LLVM 2.0 for an experiment (seriously :-)), the 2.0 frontend hangs on a program file called code/server/sv_client.c. Apparently, it's stuck on line 2964 of gcc/gcc.c while waiting for some subprocess to complete. The 1.9 frontend however does not experience this problem and is able to compile. How should I debug the frontend (currently recompiling with debugging support), as there are various threads/processes involved? Should I file a bug report? Kind regards, Bram Adams GH-SEL, INTEC, Ghent University (Belgium) From asl at math.spbu.ru Thu May 24 07:30:37 2007 From: asl at math.spbu.ru (Anton Korobeynikov) Date: Thu, 24 May 2007 16:30:37 +0400 Subject: [LLVMdev] 2.0 frontend hangs In-Reply-To: <8F087F72-9BBE-4F3D-9FC8-A11729AD68D0.SS858SS@ugent.be> References: <8F087F72-9BBE-4F3D-9FC8-A11729AD68D0.SS858SS@ugent.be> Message-ID: <1180009837.5117.89.camel@asl.dorms.spbu.ru> Hello, Bram. > How should I debug the frontend (currently recompiling with debugging > support), as there are various threads/processes involved? Should I > file a bug report? First of all, provide -v option to llvm-gcc. This will enable "verbose" output and, actually, will show you the exact command line of the tool executed. Second, determine the tool, arguments supplied, source files, etc. And try to reproduce the hang just running the tool "by hands". After you can submit bug report, which can be possible reproducible. PS: I'm trying ioquake3 on my linux box. -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University. From asl at math.spbu.ru Thu May 24 08:11:54 2007 From: asl at math.spbu.ru (Anton Korobeynikov) Date: Thu, 24 May 2007 17:11:54 +0400 Subject: [LLVMdev] 2.0 frontend hangs In-Reply-To: <8F087F72-9BBE-4F3D-9FC8-A11729AD68D0.SS858SS@ugent.be> References: <8F087F72-9BBE-4F3D-9FC8-A11729AD68D0.SS858SS@ugent.be> Message-ID: <1180012314.5117.92.camel@asl.dorms.spbu.ru> Hello, Bram. > How should I debug the frontend (currently recompiling with debugging > support), as there are various threads/processes involved? Should I > file a bug report? I filled bug report. This is bug in one of LLVM's optimization passes. You can monitor it at llvm.org/PR1446. You can workaround it now by passing -O0 to "bad" file. Thanks! -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University. From bram.adams at ugent.be Thu May 24 09:37:28 2007 From: bram.adams at ugent.be (Bram Adams) Date: Thu, 24 May 2007 16:37:28 +0200 Subject: [LLVMdev] 2.0 frontend hangs In-Reply-To: <1180012314.5117.92.camel@asl.dorms.spbu.ru> References: <8F087F72-9BBE-4F3D-9FC8-A11729AD68D0.SS858SS@ugent.be> <1180012314.5117.92.camel@asl.dorms.spbu.ru> Message-ID: <36C891D1-55AE-4AED-84B6-760C9B527063@ugent.be> Hi, Op 24-mei-07, om 15:11 heeft Anton Korobeynikov het volgende geschreven: > You can monitor it at llvm.org/PR1446. You can workaround it now by > passing -O0 to "bad" file. OK, that works. Thanks! Kind regards, Bram Adams GH-SEL, INTEC, Ghent University (Belgium) From vhernandez at apple.com Thu May 24 11:30:06 2007 From: vhernandez at apple.com (Victor Hernandez) Date: Thu, 24 May 2007 09:30:06 -0700 Subject: [LLVMdev] LLVM Developers' Meeting Message-ID: Hello, I plan to attend the meeting tomorrow. Victor --- Victor Hernandez vhernandez at apple.com Java VM Team, Apple Inc. (408) 974-1604 From kdanielson at apple.com Thu May 24 13:28:05 2007 From: kdanielson at apple.com (Kat Danielson) Date: Thu, 24 May 2007 11:28:05 -0700 Subject: [LLVMdev] LLVM Developer Meeting Message-ID: <8BFF64CE-8712-4C70-92CA-7A2765578847@apple.com> Hi, I just found out about this, and I'd like to attend. I'm in the process of getting to know llvm on a project I'm working on for Apple. Thanks, kat From isanbard at gmail.com Thu May 24 13:35:16 2007 From: isanbard at gmail.com (Bill Wendling) Date: Thu, 24 May 2007 11:35:16 -0700 Subject: [LLVMdev] LLVM Developer Meeting In-Reply-To: <8BFF64CE-8712-4C70-92CA-7A2765578847@apple.com> References: <8BFF64CE-8712-4C70-92CA-7A2765578847@apple.com> Message-ID: <16e5fdf90705241135n1daf6c35qebdb64e6551beef5@mail.gmail.com> Added. Thanks! -bw On 5/24/07, Kat Danielson wrote: > Hi, > > I just found out about this, and I'd like to attend. > > I'm in the process of getting to know llvm on a project I'm working > on for Apple. > > Thanks, > > kat > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From rspencer at reidspencer.com Thu May 24 13:36:20 2007 From: rspencer at reidspencer.com (Reid Spencer) Date: Thu, 24 May 2007 14:36:20 -0400 Subject: [LLVMdev] LLVM Developer Meeting In-Reply-To: <8BFF64CE-8712-4C70-92CA-7A2765578847@apple.com> References: <8BFF64CE-8712-4C70-92CA-7A2765578847@apple.com> Message-ID: Hi Kat, I've added you to the list. Reid. On Thu, 24 May 2007 11:28:05 -0700 Kat Danielson wrote: >Hi, > >I just found out about this, and I'd like to attend. > >I'm in the process of getting to know llvm on a project I'm working >on for Apple. > >Thanks, > >kat >_______________________________________________ >LLVM Developers mailing list >LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From sabre at nondot.org Thu May 24 15:14:35 2007 From: sabre at nondot.org (Chris Lattner) Date: Thu, 24 May 2007 13:14:35 -0700 (PDT) Subject: [LLVMdev] 2.0 frontend hangs In-Reply-To: <1180012314.5117.92.camel@asl.dorms.spbu.ru> References: <8F087F72-9BBE-4F3D-9FC8-A11729AD68D0.SS858SS@ugent.be> <1180012314.5117.92.camel@asl.dorms.spbu.ru> Message-ID: On Thu, 24 May 2007, Anton Korobeynikov wrote: >> How should I debug the frontend (currently recompiling with debugging >> support), as there are various threads/processes involved? Should I >> file a bug report? > I filled bug report. This is bug in one of LLVM's optimization passes. > You can monitor it at llvm.org/PR1446. You can workaround it now by > passing -O0 to "bad" file. Fixed. Thanks a lot for reducing this Anton! -Chris -- http://nondot.org/sabre/ http://llvm.org/ From williasr at google.com Thu May 24 18:46:04 2007 From: williasr at google.com (Scott Williams) Date: Thu, 24 May 2007 16:46:04 -0700 Subject: [LLVMdev] Room for one more at tomorrow's conference? Message-ID: <4ad6b0a30705241646j2cd80545l541ec51dfc339ea4@mail.gmail.com> Greetings llvm team! Is there room for one more (extremely tardy) attendee for the May 25 llvm developers' conference? -- Scott Williams -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20070524/f90b7ebc/attachment.html From isanbard at gmail.com Thu May 24 18:55:43 2007 From: isanbard at gmail.com (Bill Wendling) Date: Thu, 24 May 2007 16:55:43 -0700 Subject: [LLVMdev] Room for one more at tomorrow's conference? In-Reply-To: <4ad6b0a30705241646j2cd80545l541ec51dfc339ea4@mail.gmail.com> References: <4ad6b0a30705241646j2cd80545l541ec51dfc339ea4@mail.gmail.com> Message-ID: <16e5fdf90705241655i25a9d1d0g81ac6f32a11ad3f6@mail.gmail.com> On 5/24/07, Scott Williams wrote: > Greetings llvm team! Is there room for one more (extremely tardy) attendee > for the May 25 llvm developers' conference? > Sure! You're added. -bw From schaecsn at gmx.net Thu May 24 20:06:28 2007 From: schaecsn at gmx.net (schaecsn) Date: Thu, 24 May 2007 18:06:28 -0700 (PDT) Subject: [LLVMdev] Registration for the LLVM Developers' Meeting Message-ID: <20070525010628.9563D7C4035@keeper.homelinux.org> I would like attend the LLVM Developers' Meeting (http://llvm.org/DevMtgMay2007.html) Name: Stefan Sch?ckeler Organization: SCU, PhD Student Thanks for adding me to the list of attendees. Stefan From warren.armstrong at anu.edu.au Fri May 25 00:34:59 2007 From: warren.armstrong at anu.edu.au (Warren Armstrong) Date: Fri, 25 May 2007 15:34:59 +1000 Subject: [LLVMdev] Problems compiling llvm-gcc4 frontend on x86_64 Message-ID: <46567583.6060405@anu.edu.au> Hi all, I've run into problems compiling the llvm-gcc frontend on x86_64. Is this not supported, or am I making an error somewhere? The procedure I followed was: 1. Download LLVM 2.0 source as a tarball (from a few days ago, during the testing phase). 2. Download the llvm-gcc4 source today, as a tarball. 3. Extract both. 4. Configure LLVM as: ../src/configure --prefix=`pwd`../install --enable-optimized --enable-jit --enable-targets=host-only (There is no llvm-gcc in the path) 5. make ENABLE_OPTIMIZED=1 6. Configure the frontend as: ../llvm-gcc4-2.0.source/configure --prefix=`pwd`../install --program-prefix=llvm- --enable-llvm=/home/warren/llvm/obj/ --enable-languages=c,c++ --disable-shared 7. make LLVM_VERSION_INFO=2.0 This produced errors from the assembler. I reran the failing command with -v, and got the output below. I then changed the command to use -S instead of -c, the resulting assembler is attached. Any advice gratefully received. Cheers, Warren -------------- Failing command: warren at sunnyvale:~/llvm-gcc/obj/gcc> /home/warren/llvm-gcc/obj/gcc/xgcc -v -B/home/warren/llvm-gcc/obj/gcc/ -B/home/warren/llvm-gcc/obj../install/x86_64-unknown-linux-gnu/bin/ -B/home/warren/llvm-gcc/obj../install/x86_64-unknown-linux-gnu/lib/ -isystem /home/warren/llvm-gcc/obj../install/x86_64-unknown-linux-gnu/include -isystem /home/warren/llvm-gcc/obj../install/x86_64-unknown-linux-gnu/sys-include -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -I. -I32 -I../../llvm-gcc4-2.0.source/gcc -I../../llvm-gcc4-2.0.source/gcc/32 -I../../llvm-gcc4-2.0.source/gcc/../include -I../../llvm-gcc4-2.0.source/gcc/../libcpp/include -I/home/warren/llvm/llvm-2.0/include -I/home/warren/llvm/obj//include -m32 -g0 -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-unit-at-a-time -fno-omit-frame-pointer -fno-asynchronous-unwind-tables -c ../../llvm-gcc4-2.0.source/gcc/crtstuff.c -DCRT_BEGIN -o 32/crtbegin.o Reading specs from /home/warren/llvm-gcc/obj/gcc/specs Target: x86_64-unknown-linux-gnu Configured with: ../llvm-gcc4-2.0.source/configure --prefix=/home/warren/llvm-gcc/obj../install --program-prefix=llvm- --enable-llvm=/home/warren/llvm/obj/ --enable-languages=c,c++ --disable-shared Thread model: posix gcc version 4.0.1 LLVM (Apple Computer, Inc. build 2.0) /home/warren/llvm-gcc/obj/gcc/cc1 -quiet -v -I. -I32 -I../../llvm-gcc4-2.0.source/gcc -I../../llvm-gcc4-2.0.source/gcc/32 -I../../llvm-gcc4-2.0.source/gcc/../include -I../../llvm-gcc4-2.0.source/gcc/../libcpp/include -I/home/warren/llvm/llvm-2.0/include -I/home/warren/llvm/obj//include -iprefix /home/warren/llvm-gcc/obj/gcc/../lib/gcc/x86_64-unknown-linux-gnu/4.0.1/ -isystem /home/warren/llvm-gcc/obj/gcc/include -DIN_GCC -DCRT_BEGIN -isystem /home/warren/llvm-gcc/obj../install/x86_64-unknown-linux-gnu/include -isystem /home/warren/llvm-gcc/obj../install/x86_64-unknown-linux-gnu/sys-include -isystem ./include ../../llvm-gcc4-2.0.source/gcc/crtstuff.c -quiet -dumpbase crtstuff.c -m32 -mtune=generic -auxbase-strip 32/crtbegin.o -g0 -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -version -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-unit-at-a-time -fno-omit-frame-pointer -fno-asynchronous-unwind-tables -o /tmp/ccBy56Wo.s ignoring nonexistent directory "/home/warren/llvm-gcc/obj../install/x86_64-unknown-linux-gnu/include" ignoring nonexistent directory "/home/warren/llvm-gcc/obj../install/x86_64-unknown-linux-gnu/sys-include" ignoring duplicate directory "./include" ignoring nonexistent directory "/home/warren/llvm-gcc/obj/gcc/../lib/gcc/x86_64-unknown-linux-gnu/4.0.1/include" ignoring nonexistent directory "/home/warren/llvm-gcc/obj/gcc/../lib/gcc/x86_64-unknown-linux-gnu/4.0.1/../../../../x86_64-unknown-linux-gnu/include" ignoring nonexistent directory "/home/warren/llvm-gcc/obj../install/include" ignoring nonexistent directory "/home/warren/llvm-gcc/obj../install/lib/gcc/x86_64-unknown-linux-gnu/4.0.1/include" ignoring nonexistent directory "/home/warren/llvm-gcc/obj../install/x86_64-unknown-linux-gnu/include" ignoring nonexistent directory "../../llvm-gcc4-2.0.source/gcc/32" #include "..." search starts here: #include <...> search starts here: . 32 ../../llvm-gcc4-2.0.source/gcc ../../llvm-gcc4-2.0.source/gcc/../include ../../llvm-gcc4-2.0.source/gcc/../libcpp/include /home/warren/llvm/llvm-2.0/include /home/warren/llvm/obj//include /home/warren/llvm-gcc/obj/gcc/include /usr/local/include /usr/include End of search list. GNU C version 4.0.1 LLVM (Apple Computer, Inc. build 2.0) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.0.2 20050901 (prerelease) (SUSE Linux). GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Warning: Generation of 64-bit code for a 32-bit processor requested. Warning: 64-bit processors all have at least SSE2. Compiler executable checksum: efa2a522e5a08a9a5e39009754b845ec as --traditional-format -V -Qy --32 -o 32/crtbegin.o /tmp/ccBy56Wo.s GNU assembler version 2.16.91.0.2 (x86_64-suse-linux) using BFD version 2.16.91.0.2 20050720 (SuSE Linux) /tmp/ccBy56Wo.s: Assembler messages: /tmp/ccBy56Wo.s:15: Error: bad register name `%rsp' /tmp/ccBy56Wo.s:16: Error: bad register name `%rbp' /tmp/ccBy56Wo.s:17: Error: bad register name `%rsp' /tmp/ccBy56Wo.s:18: Error: `completed.4705(%rip)' is not a valid base/index expression /tmp/ccBy56Wo.s:21: Error: `p.4704(%rip)' is not a valid base/index expression /tmp/ccBy56Wo.s:22: Error: bad register name `%rax)' /tmp/ccBy56Wo.s:23: Error: bad register name `%rax' /tmp/ccBy56Wo.s:26: Error: `p.4704(%rip)' is not a valid base/index expression /tmp/ccBy56Wo.s:27: Error: bad register name `%rax' /tmp/ccBy56Wo.s:28: Error: `p.4704(%rip)' is not a valid base/index expression /tmp/ccBy56Wo.s:29: Error: bad register name `%rax)' /tmp/ccBy56Wo.s:30: Error: bad register name `%rax' /tmp/ccBy56Wo.s:33: Error: `completed.4705(%rip)' is not a valid base/index expression /tmp/ccBy56Wo.s:34: Error: bad register name `%rbp' /tmp/ccBy56Wo.s:35: Error: bad register name `%rbp' /tmp/ccBy56Wo.s:38: Error: bad register name `%rbp' /tmp/ccBy56Wo.s:39: Error: bad register name `%rbp' /tmp/ccBy56Wo.s:47: Error: bad register name `%rsp' /tmp/ccBy56Wo.s:48: Error: bad register name `%rbp' /tmp/ccBy56Wo.s:49: Error: bad register name `%rsp' /tmp/ccBy56Wo.s:50: Error: `__JCR_LIST__(%rip)' is not a valid base/index expression /tmp/ccBy56Wo.s:53: Error: `_Jv_RegisterClasses(%rip)' is not a valid base/index expression /tmp/ccBy56Wo.s:55: Error: bad register name `%rax' /tmp/ccBy56Wo.s:58: Error: `__JCR_LIST__(%rip)' is not a valid base/index expression /tmp/ccBy56Wo.s:59: Error: bad register name `%rax' /tmp/ccBy56Wo.s:60: Error: bad register name `%rbp' /tmp/ccBy56Wo.s:61: Error: bad register name `%rbp' /tmp/ccBy56Wo.s:64: Error: bad register name `%rbp' /tmp/ccBy56Wo.s:65: Error: bad register name `%rbp' -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 32crtbegin.S Url: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20070525/878f6a2f/attachment-0001.pl From figueroa at apple.com Fri May 25 01:00:24 2007 From: figueroa at apple.com (Samuel Figueroa) Date: Thu, 24 May 2007 23:00:24 -0700 Subject: [LLVMdev] LLVM Developer Meeting Message-ID: I would like to attend the LLVM Developer Meeting tomorrow in Cupertino, CA. My name is Samuel Figueroa, and I work at Apple Inc. From sabre at nondot.org Fri May 25 10:27:17 2007 From: sabre at nondot.org (Chris Lattner) Date: Fri, 25 May 2007 08:27:17 -0700 (PDT) Subject: [LLVMdev] LLVM Developer Meeting In-Reply-To: References: Message-ID: On Thu, 24 May 2007, Samuel Figueroa wrote: > I would like to attend the LLVM Developer Meeting tomorrow in > Cupertino, CA. > > My name is Samuel Figueroa, and I work at Apple Inc. No problem, added, thanks! -Chris -- http://nondot.org/sabre/ http://llvm.org/ From bram.adams at ugent.be Fri May 25 09:20:50 2007 From: bram.adams at ugent.be (Bram Adams) Date: Fri, 25 May 2007 16:20:50 +0200 Subject: [LLVMdev] Linking two external linkage GlobalValues Message-ID: <23EDA1A0-E658-4441-8BA8-D08DC252EAF0@ugent.be> Hi, I've been able to link ioquake, but not without a small modification to lib/Linker/LinkModules.cpp:427 where I had to add: } else if (Dest->hasExternalLinkage() && Src->hasExternalLinkage()){ LinkFromSrc = true;//overwrite old value LT = Src->getLinkage();//use src linkage The reason is that two files both had a global function pointer variable (due to #include's): void ( *alEnable)( ALenum capability ); which got translated to: @alEnable = globale void (i32)* null Linking these resulted in an error (lib/Linker/LinkModules.cpp's original catch-all on line 427), but our hack prevents this. My question: does this change break certain design decisions, optimisations, ...? BTW, why are the error messages of the linker, as constructed by Error (...,...), not shown on the command line? Kind regards, Bram Adams GH-SEL, INTEC, Ghent University (Belgium) From asl at math.spbu.ru Fri May 25 09:53:23 2007 From: asl at math.spbu.ru (Anton Korobeynikov) Date: Fri, 25 May 2007 18:53:23 +0400 Subject: [LLVMdev] Linking two external linkage GlobalValues In-Reply-To: <23EDA1A0-E658-4441-8BA8-D08DC252EAF0.SS1079SS@ugent.be> References: <23EDA1A0-E658-4441-8BA8-D08DC252EAF0.SS1079SS@ugent.be> Message-ID: <1180104803.5117.95.camel@asl.dorms.spbu.ru> Hello, Bram. > My question: does this change break certain design decisions, > optimisations, ...? This is bug in the source code. You have two symbols with the same name in the different object files, which is definite redefinition. At least one of them should be declared with "extern". -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University. From lee225 at uiuc.edu Fri May 25 12:21:42 2007 From: lee225 at uiuc.edu (Seung Jae Lee) Date: Fri, 25 May 2007 12:21:42 -0500 (CDT) Subject: [LLVMdev] Is 'Implicit def' bug fixed in LLVM 2.0? Message-ID: <20070525122142.AQE51878@expms2.cites.uiuc.edu> Hello, guys. I remember that Jeffrey Poznanovic posted ths issue about 'Implicit def' on Apr. 29 and Chris Lattner mentioned it seemed to be a bug. I am using ver 1.9 and also found 'Implicit def' while using codegen for the code follows: ------------------------------------------------------------- #define f c_f #define fs c_fs int f(int x1) { return x1; } int fs(){ int i, sum; for (i=0; i<10; i++) sum += f(i); return sum; } #ifdef LINUX #include #include int c_f(int); int c_fs(); int main (int argc, char* argv[]) { int j; j = c_fs(); printf ("%i\n",j); printf ("You got it\n"); } #endif ------------------------------------------------------------- The code above was converted to LLVM assembly as follows: ------------------------------------------------------------- implementation ; Functions: int %c_f(int %x1) { entry: ret int %x1 } int %c_fs() { entry: ret int undef } ------------------------------------------------------------- You can see 'int undef' at the end of this assembly which is shown as 'Implicit def' in target specific assembly code. I just wonder if this is fixed in the newer version. Have a good weekend. Thanks, Seung J. Lee From isanbard at gmail.com Fri May 25 23:56:58 2007 From: isanbard at gmail.com (Bill Wendling) Date: Fri, 25 May 2007 21:56:58 -0700 Subject: [LLVMdev] Problems compiling llvm-gcc4 frontend on x86_64 In-Reply-To: <46567583.6060405@anu.edu.au> References: <46567583.6060405@anu.edu.au> Message-ID: <342D09D4-4BA4-4E3E-B049-EF276FD3C570@gmail.com> Hi Warren, You have the -m32 flag set, but it's still giving you this: > Warning: Generation of 64-bit code for a 32-bit processor requested. > Warning: 64-bit processors all have at least SSE2. But are you sure you want to compile the LLVM-GCC source? You should use the binaries unless absolutely necessary. -bw On May 24, 2007, at 10:34 PM, Warren Armstrong wrote: > Hi all, > > I've run into problems compiling the llvm-gcc frontend on x86_64. > Is this > not supported, or am I making an error somewhere? > > The procedure I followed was: > > 1. Download LLVM 2.0 source as a tarball (from a few days ago, during > the testing phase). > 2. Download the llvm-gcc4 source today, as a tarball. > 3. Extract both. > > 4. Configure LLVM as: ../src/configure --prefix=`pwd`../install > --enable-optimized --enable-jit --enable-targets=host-only > (There is no llvm-gcc in the path) > 5. make ENABLE_OPTIMIZED=1 > > 6. Configure the frontend as: > ../llvm-gcc4-2.0.source/configure --prefix=`pwd`../install > --program-prefix=llvm- --enable-llvm=/home/warren/llvm/obj/ > --enable-languages=c,c++ --disable-shared > > 7. make LLVM_VERSION_INFO=2.0 > > This produced errors from the assembler. I reran the failing command > with -v, and got the output below. > I then changed the command to use -S instead of -c, the resulting > assembler is attached. > > Any advice gratefully received. > > Cheers, > Warren > > -------------- > > Failing command: > > > warren at sunnyvale:~/llvm-gcc/obj/gcc> /home/warren/llvm-gcc/obj/gcc/ > xgcc > -v -B/home/warren/llvm-gcc/obj/gcc/ > -B/home/warren/llvm-gcc/obj../install/x86_64-unknown-linux-gnu/bin/ > -B/home/warren/llvm-gcc/obj../install/x86_64-unknown-linux-gnu/lib/ > -isystem > /home/warren/llvm-gcc/obj../install/x86_64-unknown-linux-gnu/include > -isystem > /home/warren/llvm-gcc/obj../install/x86_64-unknown-linux-gnu/sys- > include > -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes > -Wmissing-prototypes -Wold-style-definition -isystem ./include -I. > -I32 -I../../llvm-gcc4-2.0.source/gcc > -I../../llvm-gcc4-2.0.source/gcc/32 > -I../../llvm-gcc4-2.0.source/gcc/../include > -I../../llvm-gcc4-2.0.source/gcc/../libcpp/include > -I/home/warren/llvm/llvm-2.0/include -I/home/warren/llvm/obj//include > -m32 -g0 -finhibit-size-directive -fno-inline-functions -fno- > exceptions > -fno-zero-initialized-in-bss -fno-unit-at-a-time -fno-omit-frame- > pointer > -fno-asynchronous-unwind-tables -c > ../../llvm-gcc4-2.0.source/gcc/crtstuff.c -DCRT_BEGIN -o 32/ > crtbegin.o > Reading specs from /home/warren/llvm-gcc/obj/gcc/specs > Target: x86_64-unknown-linux-gnu > Configured with: ../llvm-gcc4-2.0.source/configure > --prefix=/home/warren/llvm-gcc/obj../install --program-prefix=llvm- > --enable-llvm=/home/warren/llvm/obj/ --enable-languages=c,c++ > --disable-shared > Thread model: posix > gcc version 4.0.1 LLVM (Apple Computer, Inc. build 2.0) > /home/warren/llvm-gcc/obj/gcc/cc1 -quiet -v -I. -I32 > -I../../llvm-gcc4-2.0.source/gcc -I../../llvm-gcc4-2.0.source/gcc/32 > -I../../llvm-gcc4-2.0.source/gcc/../include > -I../../llvm-gcc4-2.0.source/gcc/../libcpp/include > -I/home/warren/llvm/llvm-2.0/include -I/home/warren/llvm/obj//include > -iprefix > /home/warren/llvm-gcc/obj/gcc/../lib/gcc/x86_64-unknown-linux-gnu/ > 4.0.1/ > -isystem /home/warren/llvm-gcc/obj/gcc/include -DIN_GCC -DCRT_BEGIN > -isystem > /home/warren/llvm-gcc/obj../install/x86_64-unknown-linux-gnu/include > -isystem > /home/warren/llvm-gcc/obj../install/x86_64-unknown-linux-gnu/sys- > include > -isystem ./include ../../llvm-gcc4-2.0.source/gcc/crtstuff.c -quiet > -dumpbase crtstuff.c -m32 -mtune=generic -auxbase-strip 32/crtbegin.o > -g0 -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes > -Wmissing-prototypes -Wold-style-definition -version > -finhibit-size-directive -fno-inline-functions -fno-exceptions > -fno-zero-initialized-in-bss -fno-unit-at-a-time -fno-omit-frame- > pointer > -fno-asynchronous-unwind-tables -o /tmp/ccBy56Wo.s > ignoring nonexistent directory > "/home/warren/llvm-gcc/obj../install/x86_64-unknown-linux-gnu/include" > ignoring nonexistent directory > "/home/warren/llvm-gcc/obj../install/x86_64-unknown-linux-gnu/sys- > include" > ignoring duplicate directory "./include" > ignoring nonexistent directory > "/home/warren/llvm-gcc/obj/gcc/../lib/gcc/x86_64-unknown-linux-gnu/ > 4.0.1/include" > ignoring nonexistent directory > "/home/warren/llvm-gcc/obj/gcc/../lib/gcc/x86_64-unknown-linux-gnu/ > 4.0.1/../../../../x86_64-unknown-linux-gnu/include" > ignoring nonexistent directory "/home/warren/llvm-gcc/obj../install/ > include" > ignoring nonexistent directory > "/home/warren/llvm-gcc/obj../install/lib/gcc/x86_64-unknown-linux- > gnu/4.0.1/include" > ignoring nonexistent directory > "/home/warren/llvm-gcc/obj../install/x86_64-unknown-linux-gnu/include" > ignoring nonexistent directory "../../llvm-gcc4-2.0.source/gcc/32" > #include "..." search starts here: > #include <...> search starts here: > . > 32 > ../../llvm-gcc4-2.0.source/gcc > ../../llvm-gcc4-2.0.source/gcc/../include > ../../llvm-gcc4-2.0.source/gcc/../libcpp/include > /home/warren/llvm/llvm-2.0/include > /home/warren/llvm/obj//include > /home/warren/llvm-gcc/obj/gcc/include > /usr/local/include > /usr/include > End of search list. > GNU C version 4.0.1 LLVM (Apple Computer, Inc. build 2.0) > (x86_64-unknown-linux-gnu) > compiled by GNU C version 4.0.2 20050901 (prerelease) (SUSE > Linux). > GGC heuristics: --param ggc-min-expand=100 --param ggc-min- > heapsize=131072 > Warning: Generation of 64-bit code for a 32-bit processor requested. > Warning: 64-bit processors all have at least SSE2. > Compiler executable checksum: efa2a522e5a08a9a5e39009754b845ec > as --traditional-format -V -Qy --32 -o 32/crtbegin.o /tmp/ccBy56Wo.s > GNU assembler version 2.16.91.0.2 (x86_64-suse-linux) using BFD > version > 2.16.91.0.2 20050720 (SuSE Linux) > /tmp/ccBy56Wo.s: Assembler messages: > /tmp/ccBy56Wo.s:15: Error: bad register name `%rsp' > /tmp/ccBy56Wo.s:16: Error: bad register name `%rbp' > /tmp/ccBy56Wo.s:17: Error: bad register name `%rsp' > /tmp/ccBy56Wo.s:18: Error: `completed.4705(%rip)' is not a valid > base/index expression > /tmp/ccBy56Wo.s:21: Error: `p.4704(%rip)' is not a valid base/index > expression > /tmp/ccBy56Wo.s:22: Error: bad register name `%rax)' > /tmp/ccBy56Wo.s:23: Error: bad register name `%rax' > /tmp/ccBy56Wo.s:26: Error: `p.4704(%rip)' is not a valid base/index > expression > /tmp/ccBy56Wo.s:27: Error: bad register name `%rax' > /tmp/ccBy56Wo.s:28: Error: `p.4704(%rip)' is not a valid base/index > expression > /tmp/ccBy56Wo.s:29: Error: bad register name `%rax)' > /tmp/ccBy56Wo.s:30: Error: bad register name `%rax' > /tmp/ccBy56Wo.s:33: Error: `completed.4705(%rip)' is not a valid > base/index expression > /tmp/ccBy56Wo.s:34: Error: bad register name `%rbp' > /tmp/ccBy56Wo.s:35: Error: bad register name `%rbp' > /tmp/ccBy56Wo.s:38: Error: bad register name `%rbp' > /tmp/ccBy56Wo.s:39: Error: bad register name `%rbp' > /tmp/ccBy56Wo.s:47: Error: bad register name `%rsp' > /tmp/ccBy56Wo.s:48: Error: bad register name `%rbp' > /tmp/ccBy56Wo.s:49: Error: bad register name `%rsp' > /tmp/ccBy56Wo.s:50: Error: `__JCR_LIST__(%rip)' is not a valid > base/index expression > /tmp/ccBy56Wo.s:53: Error: `_Jv_RegisterClasses(%rip)' is not a valid > base/index expression > /tmp/ccBy56Wo.s:55: Error: bad register name `%rax' > /tmp/ccBy56Wo.s:58: Error: `__JCR_LIST__(%rip)' is not a valid > base/index expression > /tmp/ccBy56Wo.s:59: Error: bad register name `%rax' > /tmp/ccBy56Wo.s:60: Error: bad register name `%rbp' > /tmp/ccBy56Wo.s:61: Error: bad register name `%rbp' > /tmp/ccBy56Wo.s:64: Error: bad register name `%rbp' > /tmp/ccBy56Wo.s:65: Error: bad register name `%rbp' > > # Start of file scope inline assembly > .section .fini > call __do_global_dtors_aux > .text > .section .init > call frame_dummy > .text > # End of file scope inline assembly > > > .text > .align 16 > .type __do_global_dtors_aux, at function > __do_global_dtors_aux: > subq $8, %rsp > movq %rbp, (%rsp) > movq %rsp, %rbp > cmpb $0, completed.4705(%rip) > jne .LBB1_4 #UnifiedReturnBlock > .LBB1_1: #bb9.preheader > movq p.4704(%rip), %rax > movq (%rax), %rax > cmpq $0, %rax > je .LBB1_3 #bb16 > .LBB1_2: #bb > addq $4, p.4704(%rip) > call *%rax > movq p.4704(%rip), %rax > movq (%rax), %rax > cmpq $0, %rax > jne .LBB1_2 #bb > .LBB1_3: #bb16 > movb $1, completed.4705(%rip) > movq %rbp, %rsp > popq %rbp > ret > .LBB1_4: #UnifiedReturnBlock > movq %rbp, %rsp > popq %rbp > ret > .size __do_global_dtors_aux, .-__do_global_dtors_aux > > > .align 16 > .type frame_dummy, at function > frame_dummy: > subq $8, %rsp > movq %rbp, (%rsp) > movq %rsp, %rbp > cmpq $0, __JCR_LIST__(%rip) > je .LBB2_3 #UnifiedReturnBlock > .LBB2_1: #cond_true > leaq _Jv_RegisterClasses(%rip), %rax > > cmpq $0, %rax > je .LBB2_3 #UnifiedReturnBlock > .LBB2_2: #cond_true10 > leaq __JCR_LIST__(%rip), %rdi > call *%rax > movq %rbp, %rsp > popq %rbp > ret > .LBB2_3: #UnifiedReturnBlock > movq %rbp, %rsp > popq %rbp > ret > .size frame_dummy, .-frame_dummy > .type __CTOR_LIST__, at object > .section .ctors,"aw", at progbits > .align 8 > __CTOR_LIST__: # __CTOR_LIST__ > .size __CTOR_LIST__, 8 > .quad 4294967295 > > .type __DTOR_LIST__, at object > .section .dtors,"aw", at progbits > .align 8 > __DTOR_LIST__: # __DTOR_LIST__ > .size __DTOR_LIST__, 8 > .quad 4294967295 > > .type __JCR_LIST__, at object > .section .jcr > .align 8 > __JCR_LIST__: # __JCR_LIST__ > .size __JCR_LIST__, 0 > > .hidden __dso_handle > .type __dso_handle, at object > .globl __dso_handle > .data > .align 8 > __dso_handle: # __dso_handle > .size __dso_handle, 8 > .zero 8 > > .type p.4704, at object > .align 8 > p.4704: # p.4704 > .size p.4704, 8 > .quad (__DTOR_LIST__) + 8 > > .type completed.4705, at object > .local completed.4705 > .comm completed.4705,1,1 # completed.4705 > .weak _Jv_RegisterClasses > > .ident "GCC: (GNU) 4.0.1 LLVM (Apple Computer, Inc. build 2.0)" > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From sarah at findatlantis.com Fri May 25 10:22:59 2007 From: sarah at findatlantis.com (Sarah Thompson) Date: Fri, 25 May 2007 08:22:59 -0700 Subject: [LLVMdev] LLVM Developer Meeting In-Reply-To: References: Message-ID: <4656FF53.7050802@findatlantis.com> Hi folks, I am very sorry, but I'll not be able to attend the developer's meeting. I came down with a nasty stomach bug yesterday, and am frankly in no fit state to do anything much. Many apologies, Sarah Thompson From sabre at nondot.org Sat May 26 02:27:25 2007 From: sabre at nondot.org (Chris Lattner) Date: Sat, 26 May 2007 00:27:25 -0700 (PDT) Subject: [LLVMdev] LLVM Developer Meeting In-Reply-To: <4656FF53.7050802@findatlantis.com> References: <4656FF53.7050802@findatlantis.com> Message-ID: > I am very sorry, but I'll not be able to attend the developer's meeting. > I came down with a nasty stomach bug yesterday, and am frankly in no fit > state to do anything much. Hey Sarah, I'm sorry to hear you weren't feeling well, we missed you! We adapted on the fly, hopefully you'll make it next year, -Chris -- http://nondot.org/sabre/ http://llvm.org/ From sabre at nondot.org Sat May 26 02:29:36 2007 From: sabre at nondot.org (Chris Lattner) Date: Sat, 26 May 2007 00:29:36 -0700 (PDT) Subject: [LLVMdev] Is 'Implicit def' bug fixed in LLVM 2.0? In-Reply-To: <20070525122142.AQE51878@expms2.cites.uiuc.edu> References: <20070525122142.AQE51878@expms2.cites.uiuc.edu> Message-ID: On Fri, 25 May 2007, Seung Jae Lee wrote: > I remember that Jeffrey Poznanovic posted ths issue about 'Implicit def' > on Apr. 29 and Chris Lattner mentioned it seemed to be a bug. Ok, I don't recall the bug but: > I am using ver 1.9 and also found 'Implicit def' while using codegen for > the code follows: The implicit def instruction often comes from use of the 'undef' value. In your case, that comes from this function > int %c_fs() { > entry: > ret int undef > } > So your real question seems to be why the llvm optimizer reduces c_fs to undef. The answer is because your code is not computing a defined value: > int c_fs(){ > int i, sum; > for (i=0; i<10; i++) > sum += f(i); > return sum; > } Try initializing 'sum' to zero. -Chris > #ifdef LINUX > #include > #include > > int c_f(int); > int c_fs(); > > int main (int argc, char* argv[]) { > int j; > j = c_fs(); > > printf ("%i\n",j); > printf ("You got it\n"); > > } > #endif > ------------------------------------------------------------- > The code above was converted to LLVM assembly as follows: > > ------------------------------------------------------------- > implementation ; Functions: > > int %c_f(int %x1) { > entry: > ret int %x1 > } > > ------------------------------------------------------------- > > You can see 'int undef' at the end of this assembly which is shown as 'Implicit def' in target specific assembly code. > > I just wonder if this is fixed in the newer version. > Have a good weekend. > > Thanks, > Seung J. Lee > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > -Chris -- http://nondot.org/sabre/ http://llvm.org/ From sabre at nondot.org Sat May 26 02:46:42 2007 From: sabre at nondot.org (Chris Lattner) Date: Sat, 26 May 2007 00:46:42 -0700 (PDT) Subject: [LLVMdev] Random notes on the llvm developer meeting Message-ID: Hi Everyone, The first LLVM Developer Meeting seems to have been a great success! People are using LLVM in many interesting ways, and the excitement level seemed generally very high. Many thanks to the speakers, attendees, and organizers. I really enjoyed meeting all of you, and it's great to now be able to put faces together with names. From an informal poll, about 20% of attendees flew in, and just about everyone seemed to want to do it again :). Speakers: please send me a copy of your slides in .PDF format for future reference and for those who couldn't make it. I'll put together a page to host them. Also, random nagging note: please send a picture to be included on http://llvm.org/developers.cgi . If you have contributed code or a bugfix, you should be on this page :) For those who couldn't attend, we video taped all of the talks and official discussions (many thanks to Tanya for making this happen). Assuming the tapes are all good etc, we'll put the videos up somewhere in a week or two. Anyway, happy hacking all, -Chris -- http://nondot.org/sabre/ http://llvm.org/ From feradz at gmail.com Sat May 26 02:39:51 2007 From: feradz at gmail.com (Ferad Zyulkyarov) Date: Sat, 26 May 2007 09:39:51 +0200 Subject: [LLVMdev] Problems compiling llvm-gcc4 frontend on x86_64 In-Reply-To: <342D09D4-4BA4-4E3E-B049-EF276FD3C570@gmail.com> References: <46567583.6060405@anu.edu.au> <342D09D4-4BA4-4E3E-B049-EF276FD3C570@gmail.com> Message-ID: Hi Warren, you can try to configure with the following export CFLAGS="-m64" export LDFLAGS="-L/usr/lib64" LLVM: ../src/configure --prefix=`pwd`../install --enable-optimized --enable-jit --enable-targets=host-only make LLVM-GCC: ../llvm-gcc4-2.0.source/configure --prefix=`pwd`../install --program-prefix=llvm- --enable-llvm=/home/warren/llvm/obj/ --enable-languages=c,c++ --disable-shared --disable-multilib make Sometimes the gcc you use to compile matters. I wasn't able to compile with 4.1.* for example. I use 4.0.4 right now. Regards, Ferad Zyulkyarov On 5/26/07, Bill Wendling wrote: > > Hi Warren, > > You have the -m32 flag set, but it's still giving you this: > > > Warning: Generation of 64-bit code for a 32-bit processor requested. > > Warning: 64-bit processors all have at least SSE2. > > But are you sure you want to compile the LLVM-GCC source? You should > use the binaries unless absolutely necessary. > > -bw > > On May 24, 2007, at 10:34 PM, Warren Armstrong wrote: > > > Hi all, > > > > I've run into problems compiling the llvm-gcc frontend on x86_64. > > Is this > > not supported, or am I making an error somewhere? > > > > The procedure I followed was: > > > > 1. Download LLVM 2.0 source as a tarball (from a few days ago, during > > the testing phase). > > 2. Download the llvm-gcc4 source today, as a tarball. > > 3. Extract both. > > > > 4. Configure LLVM as: ../src/configure --prefix=`pwd`../install > > --enable-optimized --enable-jit --enable-targets=host-only > > (There is no llvm-gcc in the path) > > 5. make ENABLE_OPTIMIZED=1 > > > > 6. Configure the frontend as: > > ../llvm-gcc4-2.0.source/configure --prefix=`pwd`../install > > --program-prefix=llvm- --enable-llvm=/home/warren/llvm/obj/ > > --enable-languages=c,c++ --disable-shared > > > > 7. make LLVM_VERSION_INFO=2.0 > > > > This produced errors from the assembler. I reran the failing command > > with -v, and got the output below. > > I then changed the command to use -S instead of -c, the resulting > > assembler is attached. > > > > Any advice gratefully received. > > > > Cheers, > > Warren > > > > -------------- > > > > Failing command: > > > > > > warren at sunnyvale:~/llvm-gcc/obj/gcc> /home/warren/llvm-gcc/obj/gcc/ > > xgcc > > -v -B/home/warren/llvm-gcc/obj/gcc/ > > -B/home/warren/llvm-gcc/obj../install/x86_64-unknown-linux-gnu/bin/ > > -B/home/warren/llvm-gcc/obj../install/x86_64-unknown-linux-gnu/lib/ > > -isystem > > /home/warren/llvm-gcc/obj../install/x86_64-unknown-linux-gnu/include > > -isystem > > /home/warren/llvm-gcc/obj../install/x86_64-unknown-linux-gnu/sys- > > include > > -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes > > -Wmissing-prototypes -Wold-style-definition -isystem ./include -I. > > -I32 -I../../llvm-gcc4-2.0.source/gcc > > -I../../llvm-gcc4-2.0.source/gcc/32 > > -I../../llvm-gcc4-2.0.source/gcc/../include > > -I../../llvm-gcc4-2.0.source/gcc/../libcpp/include > > -I/home/warren/llvm/llvm-2.0/include -I/home/warren/llvm/obj//include > > -m32 -g0 -finhibit-size-directive -fno-inline-functions -fno- > > exceptions > > -fno-zero-initialized-in-bss -fno-unit-at-a-time -fno-omit-frame- > > pointer > > -fno-asynchronous-unwind-tables -c > > ../../llvm-gcc4-2.0.source/gcc/crtstuff.c -DCRT_BEGIN -o 32/ > > crtbegin.o > > Reading specs from /home/warren/llvm-gcc/obj/gcc/specs > > Target: x86_64-unknown-linux-gnu > > Configured with: ../llvm-gcc4-2.0.source/configure > > --prefix=/home/warren/llvm-gcc/obj../install --program-prefix=llvm- > > --enable-llvm=/home/warren/llvm/obj/ --enable-languages=c,c++ > > --disable-shared > > Thread model: posix > > gcc version 4.0.1 LLVM (Apple Computer, Inc. build 2.0) > > /home/warren/llvm-gcc/obj/gcc/cc1 -quiet -v -I. -I32 > > -I../../llvm-gcc4-2.0.source/gcc -I../../llvm-gcc4-2.0.source/gcc/32 > > -I../../llvm-gcc4-2.0.source/gcc/../include > > -I../../llvm-gcc4-2.0.source/gcc/../libcpp/include > > -I/home/warren/llvm/llvm-2.0/include -I/home/warren/llvm/obj//include > > -iprefix > > /home/warren/llvm-gcc/obj/gcc/../lib/gcc/x86_64-unknown-linux-gnu/ > > 4.0.1/ > > -isystem /home/warren/llvm-gcc/obj/gcc/include -DIN_GCC -DCRT_BEGIN > > -isystem > > /home/warren/llvm-gcc/obj../install/x86_64-unknown-linux-gnu/include > > -isystem > > /home/warren/llvm-gcc/obj../install/x86_64-unknown-linux-gnu/sys- > > include > > -isystem ./include ../../llvm-gcc4-2.0.source/gcc/crtstuff.c -quiet > > -dumpbase crtstuff.c -m32 -mtune=generic -auxbase-strip 32/crtbegin.o > > -g0 -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes > > -Wmissing-prototypes -Wold-style-definition -version > > -finhibit-size-directive -fno-inline-functions -fno-exceptions > > -fno-zero-initialized-in-bss -fno-unit-at-a-time -fno-omit-frame- > > pointer > > -fno-asynchronous-unwind-tables -o /tmp/ccBy56Wo.s > > ignoring nonexistent directory > > "/home/warren/llvm-gcc/obj../install/x86_64-unknown-linux-gnu/include" > > ignoring nonexistent directory > > "/home/warren/llvm-gcc/obj../install/x86_64-unknown-linux-gnu/sys- > > include" > > ignoring duplicate directory "./include" > > ignoring nonexistent directory > > "/home/warren/llvm-gcc/obj/gcc/../lib/gcc/x86_64-unknown-linux-gnu/ > > 4.0.1/include" > > ignoring nonexistent directory > > "/home/warren/llvm-gcc/obj/gcc/../lib/gcc/x86_64-unknown-linux-gnu/ > > 4.0.1/../../../../x86_64-unknown-linux-gnu/include" > > ignoring nonexistent directory "/home/warren/llvm-gcc/obj../install/ > > include" > > ignoring nonexistent directory > > "/home/warren/llvm-gcc/obj../install/lib/gcc/x86_64-unknown-linux- > > gnu/4.0.1/include" > > ignoring nonexistent directory > > "/home/warren/llvm-gcc/obj../install/x86_64-unknown-linux-gnu/include" > > ignoring nonexistent directory "../../llvm-gcc4-2.0.source/gcc/32" > > #include "..." search starts here: > > #include <...> search starts here: > > . > > 32 > > ../../llvm-gcc4-2.0.source/gcc > > ../../llvm-gcc4-2.0.source/gcc/../include > > ../../llvm-gcc4-2.0.source/gcc/../libcpp/include > > /home/warren/llvm/llvm-2.0/include > > /home/warren/llvm/obj//include > > /home/warren/llvm-gcc/obj/gcc/include > > /usr/local/include > > /usr/include > > End of search list. > > GNU C version 4.0.1 LLVM (Apple Computer, Inc. build 2.0) > > (x86_64-unknown-linux-gnu) > > compiled by GNU C version 4.0.2 20050901 (prerelease) (SUSE > > Linux). > > GGC heuristics: --param ggc-min-expand=100 --param ggc-min- > > heapsize=131072 > > Warning: Generation of 64-bit code for a 32-bit processor requested. > > Warning: 64-bit processors all have at least SSE2. > > Compiler executable checksum: efa2a522e5a08a9a5e39009754b845ec > > as --traditional-format -V -Qy --32 -o 32/crtbegin.o /tmp/ccBy56Wo.s > > GNU assembler version 2.16.91.0.2 (x86_64-suse-linux) using BFD > > version > > 2.16.91.0.2 20050720 (SuSE Linux) > > /tmp/ccBy56Wo.s: Assembler messages: > > /tmp/ccBy56Wo.s:15: Error: bad register name `%rsp' > > /tmp/ccBy56Wo.s:16: Error: bad register name `%rbp' > > /tmp/ccBy56Wo.s:17: Error: bad register name `%rsp' > > /tmp/ccBy56Wo.s:18: Error: `completed.4705(%rip)' is not a valid > > base/index expression > > /tmp/ccBy56Wo.s:21: Error: `p.4704(%rip)' is not a valid base/index > > expression > > /tmp/ccBy56Wo.s:22: Error: bad register name `%rax)' > > /tmp/ccBy56Wo.s:23: Error: bad register name `%rax' > > /tmp/ccBy56Wo.s:26: Error: `p.4704(%rip)' is not a valid base/index > > expression > > /tmp/ccBy56Wo.s:27: Error: bad register name `%rax' > > /tmp/ccBy56Wo.s:28: Error: `p.4704(%rip)' is not a valid base/index > > expression > > /tmp/ccBy56Wo.s:29: Error: bad register name `%rax)' > > /tmp/ccBy56Wo.s:30: Error: bad register name `%rax' > > /tmp/ccBy56Wo.s:33: Error: `completed.4705(%rip)' is not a valid > > base/index expression > > /tmp/ccBy56Wo.s:34: Error: bad register name `%rbp' > > /tmp/ccBy56Wo.s:35: Error: bad register name `%rbp' > > /tmp/ccBy56Wo.s:38: Error: bad register name `%rbp' > > /tmp/ccBy56Wo.s:39: Error: bad register name `%rbp' > > /tmp/ccBy56Wo.s:47: Error: bad register name `%rsp' > > /tmp/ccBy56Wo.s:48: Error: bad register name `%rbp' > > /tmp/ccBy56Wo.s:49: Error: bad register name `%rsp' > > /tmp/ccBy56Wo.s:50: Error: `__JCR_LIST__(%rip)' is not a valid > > base/index expression > > /tmp/ccBy56Wo.s:53: Error: `_Jv_RegisterClasses(%rip)' is not a valid > > base/index expression > > /tmp/ccBy56Wo.s:55: Error: bad register name `%rax' > > /tmp/ccBy56Wo.s:58: Error: `__JCR_LIST__(%rip)' is not a valid > > base/index expression > > /tmp/ccBy56Wo.s:59: Error: bad register name `%rax' > > /tmp/ccBy56Wo.s:60: Error: bad register name `%rbp' > > /tmp/ccBy56Wo.s:61: Error: bad register name `%rbp' > > /tmp/ccBy56Wo.s:64: Error: bad register name `%rbp' > > /tmp/ccBy56Wo.s:65: Error: bad register name `%rbp' > > > > # Start of file scope inline assembly > > .section .fini > > call __do_global_dtors_aux > > .text > > .section .init > > call frame_dummy > > .text > > # End of file scope inline assembly > > > > > > .text > > .align 16 > > .type __do_global_dtors_aux, at function > > __do_global_dtors_aux: > > subq $8, %rsp > > movq %rbp, (%rsp) > > movq %rsp, %rbp > > cmpb $0, completed.4705(%rip) > > jne .LBB1_4 #UnifiedReturnBlock > > .LBB1_1: #bb9.preheader > > movq p.4704(%rip), %rax > > movq (%rax), %rax > > cmpq $0, %rax > > je .LBB1_3 #bb16 > > .LBB1_2: #bb > > addq $4, p.4704(%rip) > > call *%rax > > movq p.4704(%rip), %rax > > movq (%rax), %rax > > cmpq $0, %rax > > jne .LBB1_2 #bb > > .LBB1_3: #bb16 > > movb $1, completed.4705(%rip) > > movq %rbp, %rsp > > popq %rbp > > ret > > .LBB1_4: #UnifiedReturnBlock > > movq %rbp, %rsp > > popq %rbp > > ret > > .size __do_global_dtors_aux, .-__do_global_dtors_aux > > > > > > .align 16 > > .type frame_dummy, at function > > frame_dummy: > > subq $8, %rsp > > movq %rbp, (%rsp) > > movq %rsp, %rbp > > cmpq $0, __JCR_LIST__(%rip) > > je .LBB2_3 #UnifiedReturnBlock > > .LBB2_1: #cond_true > > leaq _Jv_RegisterClasses(%rip), %rax > > > > cmpq $0, %rax > > je .LBB2_3 #UnifiedReturnBlock > > .LBB2_2: #cond_true10 > > leaq __JCR_LIST__(%rip), %rdi > > call *%rax > > movq %rbp, %rsp > > popq %rbp > > ret > > .LBB2_3: #UnifiedReturnBlock > > movq %rbp, %rsp > > popq %rbp > > ret > > .size frame_dummy, .-frame_dummy > > .type __CTOR_LIST__, at object > > .section .ctors,"aw", at progbits > > .align 8 > > __CTOR_LIST__: # __CTOR_LIST__ > > .size __CTOR_LIST__, 8 > > .quad 4294967295 > > > > .type __DTOR_LIST__, at object > > .section .dtors,"aw", at progbits > > .align 8 > > __DTOR_LIST__: # __DTOR_LIST__ > > .size __DTOR_LIST__, 8 > > .quad 4294967295 > > > > .type __JCR_LIST__, at object > > .section .jcr > > .align 8 > > __JCR_LIST__: # __JCR_LIST__ > > .size __JCR_LIST__, 0 > > > > .hidden __dso_handle > > .type __dso_handle, at object > > .globl __dso_handle > > .data > > .align 8 > > __dso_handle: # __dso_handle > > .size __dso_handle, 8 > > .zero 8 > > > > .type p.4704, at object > > .align 8 > > p.4704: # p.4704 > > .size p.4704, 8 > > .quad (__DTOR_LIST__) + 8 > > > > .type completed.4705, at object > > .local completed.4705 > > .comm completed.4705,1,1 # completed.4705 > > .weak _Jv_RegisterClasses > > > > .ident "GCC: (GNU) 4.0.1 LLVM (Apple Computer, Inc. build 2.0)" > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20070526/8a2accd5/attachment-0001.html From sabre at nondot.org Sat May 26 16:14:17 2007 From: sabre at nondot.org (Chris Lattner) Date: Sat, 26 May 2007 14:14:17 -0700 (PDT) Subject: [LLVMdev] Linking two external linkage GlobalValues In-Reply-To: <1180104803.5117.95.camel@asl.dorms.spbu.ru> References: <23EDA1A0-E658-4441-8BA8-D08DC252EAF0.SS1079SS@ugent.be> <1180104803.5117.95.camel@asl.dorms.spbu.ru> Message-ID: On Fri, 25 May 2007, Anton Korobeynikov wrote: >> My question: does this change break certain design decisions, >> optimisations, ...? > This is bug in the source code. You have two symbols with the same name > in the different object files, which is definite redefinition. At least > one of them should be declared with "extern". Shouldn't these symbols get "common" linkage, aka llvm weak linkage? Are you building the source with -fno-common? If not, it could be an llvm bug. -Chris -- http://nondot.org/sabre/ http://llvm.org/ From ralph at inputplus.co.uk Sat May 26 15:16:35 2007 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Sat, 26 May 2007 21:16:35 +0100 Subject: [LLVMdev] Linking two external linkage GlobalValues In-Reply-To: <1180104803.5117.95.camel@asl.dorms.spbu.ru> References: <23EDA1A0-E658-4441-8BA8-D08DC252EAF0.SS1079SS@ugent.be> <1180104803.5117.95.camel@asl.dorms.spbu.ru> Message-ID: <20070526201635.6D3C1149A69@blake.inputplus.co.uk> Hi Anton, > This is bug in the source code. You have two symbols with the same > name in the different object files, which is definite redefinition. At > least one of them should be declared with "extern". C allows this. $ head foo.c bar.c ==> foo.c <== void bar(); int foo; int main() { bar(); return foo; } ==> bar.c <== int foo; void bar() { foo = 42; return; } $ gcc -Wall foo.c bar.c && ./a.out; echo $? 42 $ Better practice to have one definition I agree, but it's valid C. Cheers, Ralph. From bram.adams at ugent.be Sat May 26 15:50:15 2007 From: bram.adams at ugent.be (Bram Adams) Date: Sat, 26 May 2007 22:50:15 +0200 Subject: [LLVMdev] Linking two external linkage GlobalValues In-Reply-To: References: <23EDA1A0-E658-4441-8BA8-D08DC252EAF0.SS1079SS@ugent.be> <1180104803.5117.95.camel@asl.dorms.spbu.ru> Message-ID: <603A38F2-0CAF-414D-8A49-BBC5461D2984@ugent.be> Hi, Op 26-mei-07, om 23:14 heeft Chris Lattner het volgende geschreven: > Shouldn't these symbols get "common" linkage, aka llvm weak linkage? > > Are you building the source with -fno-common? Yes. What does this mean? Kind regards, Bram Adams GH-SEL, INTEC, Ghent University (Belgium) From sabre at nondot.org Sat May 26 17:45:57 2007 From: sabre at nondot.org (Chris Lattner) Date: Sat, 26 May 2007 15:45:57 -0700 (PDT) Subject: [LLVMdev] Linking two external linkage GlobalValues In-Reply-To: <603A38F2-0CAF-414D-8A49-BBC5461D2984@ugent.be> References: <23EDA1A0-E658-4441-8BA8-D08DC252EAF0.SS1079SS@ugent.be> <1180104803.5117.95.camel@asl.dorms.spbu.ru> <603A38F2-0CAF-414D-8A49-BBC5461D2984@ugent.be> Message-ID: On Sat, 26 May 2007, Bram Adams wrote: > >> Shouldn't these symbols get "common" linkage, aka llvm weak linkage? >> >> Are you building the source with -fno-common? > > Yes. What does this mean? -fno-common is a performance win on some targets, but it disallows merging of global variables that are defined with no initializers (like your example). Please remove -fno-common, if it builds correctly, then it is not an llvm bug. -Chris -- http://nondot.org/sabre/ http://llvm.org/ From scott.llvm at h4ck3r.net Sun May 27 00:54:16 2007 From: scott.llvm at h4ck3r.net (Scott Graham) Date: Sat, 26 May 2007 22:54:16 -0700 Subject: [LLVMdev] Problem building 2.0 release with .sln on win32 (and patch) Message-ID: <84decce20705262254y3cabf003r24fa806ad42b0d1c@mail.gmail.com> Hi I was getting an error building the x86 project using the .sln included with the 2.0 release. VS was unable run the Custom Build Step for X86.td for reasons which were not clear to me. It spit out an obtuse "Format of the path is incorrect" error, and then proceeded to run only the last 4 lines of the custom build step for X86.td. (??) Is there something obvious that I'm missing? Assuming not, I have attached a patch that works around the problem by putting the invocations of TableGen into a standalone .cmd file, and using that in the custom build step for X86.td. This allowed me to successfully build the x86 lib and in turn the llc, lli, and Fibonacci projects. They seem to run OK, but I've only just started looking at LLVM so I probably wouldn't know if things were broken anyhow. scott -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20070526/996d0bf3/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: fix-win-sln-build.patch Type: application/octet-stream Size: 8965 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20070526/996d0bf3/attachment.obj From warren.armstrong at anu.edu.au Sun May 27 08:23:43 2007 From: warren.armstrong at anu.edu.au (Warren Armstrong) Date: Sun, 27 May 2007 23:23:43 +1000 Subject: [LLVMdev] Problems compiling llvm-gcc4 frontend on x86_64 In-Reply-To: <342D09D4-4BA4-4E3E-B049-EF276FD3C570@gmail.com> References: <46567583.6060405@anu.edu.au> <342D09D4-4BA4-4E3E-B049-EF276FD3C570@gmail.com> Message-ID: <4659865F.2020705@anu.edu.au> Hi Bill, I didn't explicitly set -m32, but I tried redoing things with -m64, and everything works fine. The reason I was using the source version is that I was running into the same sort of error when trying to compile C code - my simple Hello World C program was failing to compile, with error messages from the assembler similar to those reported below. When I passed -v to llvm-gcc, it reported that it was configured for x86, but the local assembler (gnu as) was configured for x86_64 - I thought there might be a mismatch there. Hence I decided to try with a copy of llvm-gcc configured for x86_64. Cheers, Warren Bill Wendling wrote: > Hi Warren, > > You have the -m32 flag set, but it's still giving you this: > >> Warning: Generation of 64-bit code for a 32-bit processor requested. >> Warning: 64-bit processors all have at least SSE2. > > But are you sure you want to compile the LLVM-GCC source? You should > use the binaries unless absolutely necessary. > > -bw > > On May 24, 2007, at 10:34 PM, Warren Armstrong wrote: > >> Hi all, >> >> I've run into problems compiling the llvm-gcc frontend on x86_64. >> Is this >> not supported, or am I making an error somewhere? >> >> The procedure I followed was: >> >> 1. Download LLVM 2.0 source as a tarball (from a few days ago, during >> the testing phase). >> 2. Download the llvm-gcc4 source today, as a tarball. >> 3. Extract both. >> >> 4. Configure LLVM as: ../src/configure --prefix=`pwd`../install >> --enable-optimized --enable-jit --enable-targets=host-only >> (There is no llvm-gcc in the path) >> 5. make ENABLE_OPTIMIZED=1 >> >> 6. Configure the frontend as: >> ../llvm-gcc4-2.0.source/configure --prefix=`pwd`../install >> --program-prefix=llvm- --enable-llvm=/home/warren/llvm/obj/ >> --enable-languages=c,c++ --disable-shared >> >> 7. make LLVM_VERSION_INFO=2.0 >> >> This produced errors from the assembler. I reran the failing command >> with -v, and got the output below. >> I then changed the command to use -S instead of -c, the resulting >> assembler is attached. >> >> Any advice gratefully received. >> >> Cheers, >> Warren >> >> -------------- >> >> Failing command: >> >> >> warren at sunnyvale:~/llvm-gcc/obj/gcc> /home/warren/llvm-gcc/obj/gcc/ >> xgcc >> -v -B/home/warren/llvm-gcc/obj/gcc/ >> -B/home/warren/llvm-gcc/obj../install/x86_64-unknown-linux-gnu/bin/ >> -B/home/warren/llvm-gcc/obj../install/x86_64-unknown-linux-gnu/lib/ >> -isystem >> /home/warren/llvm-gcc/obj../install/x86_64-unknown-linux-gnu/include >> -isystem >> /home/warren/llvm-gcc/obj../install/x86_64-unknown-linux-gnu/sys- >> include >> -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes >> -Wmissing-prototypes -Wold-style-definition -isystem ./include -I. >> -I32 -I../../llvm-gcc4-2.0.source/gcc >> -I../../llvm-gcc4-2.0.source/gcc/32 >> -I../../llvm-gcc4-2.0.source/gcc/../include >> -I../../llvm-gcc4-2.0.source/gcc/../libcpp/include >> -I/home/warren/llvm/llvm-2.0/include -I/home/warren/llvm/obj//include >> -m32 -g0 -finhibit-size-directive -fno-inline-functions -fno- >> exceptions >> -fno-zero-initialized-in-bss -fno-unit-at-a-time -fno-omit-frame- >> pointer >> -fno-asynchronous-unwind-tables -c >> ../../llvm-gcc4-2.0.source/gcc/crtstuff.c -DCRT_BEGIN -o 32/ >> crtbegin.o >> Reading specs from /home/warren/llvm-gcc/obj/gcc/specs >> Target: x86_64-unknown-linux-gnu >> Configured with: ../llvm-gcc4-2.0.source/configure >> --prefix=/home/warren/llvm-gcc/obj../install --program-prefix=llvm- >> --enable-llvm=/home/warren/llvm/obj/ --enable-languages=c,c++ >> --disable-shared >> Thread model: posix >> gcc version 4.0.1 LLVM (Apple Computer, Inc. build 2.0) >> /home/warren/llvm-gcc/obj/gcc/cc1 -quiet -v -I. -I32 >> -I../../llvm-gcc4-2.0.source/gcc -I../../llvm-gcc4-2.0.source/gcc/32 >> -I../../llvm-gcc4-2.0.source/gcc/../include >> -I../../llvm-gcc4-2.0.source/gcc/../libcpp/include >> -I/home/warren/llvm/llvm-2.0/include -I/home/warren/llvm/obj//include >> -iprefix >> /home/warren/llvm-gcc/obj/gcc/../lib/gcc/x86_64-unknown-linux-gnu/ >> 4.0.1/ >> -isystem /home/warren/llvm-gcc/obj/gcc/include -DIN_GCC -DCRT_BEGIN >> -isystem >> /home/warren/llvm-gcc/obj../install/x86_64-unknown-linux-gnu/include >> -isystem >> /home/warren/llvm-gcc/obj../install/x86_64-unknown-linux-gnu/sys- >> include >> -isystem ./include ../../llvm-gcc4-2.0.source/gcc/crtstuff.c -quiet >> -dumpbase crtstuff.c -m32 -mtune=generic -auxbase-strip 32/crtbegin.o >> -g0 -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes >> -Wmissing-prototypes -Wold-style-definition -version >> -finhibit-size-directive -fno-inline-functions -fno-exceptions >> -fno-zero-initialized-in-bss -fno-unit-at-a-time -fno-omit-frame- >> pointer >> -fno-asynchronous-unwind-tables -o /tmp/ccBy56Wo.s >> ignoring nonexistent directory >> "/home/warren/llvm-gcc/obj../install/x86_64-unknown-linux-gnu/include" >> ignoring nonexistent directory >> "/home/warren/llvm-gcc/obj../install/x86_64-unknown-linux-gnu/sys- >> include" >> ignoring duplicate directory "./include" >> ignoring nonexistent directory >> "/home/warren/llvm-gcc/obj/gcc/../lib/gcc/x86_64-unknown-linux-gnu/ >> 4.0.1/include" >> ignoring nonexistent directory >> "/home/warren/llvm-gcc/obj/gcc/../lib/gcc/x86_64-unknown-linux-gnu/ >> 4.0.1/../../../../x86_64-unknown-linux-gnu/include" >> ignoring nonexistent directory "/home/warren/llvm-gcc/obj../install/ >> include" >> ignoring nonexistent directory >> "/home/warren/llvm-gcc/obj../install/lib/gcc/x86_64-unknown-linux- >> gnu/4.0.1/include" >> ignoring nonexistent directory >> "/home/warren/llvm-gcc/obj../install/x86_64-unknown-linux-gnu/include" >> ignoring nonexistent directory "../../llvm-gcc4-2.0.source/gcc/32" >> #include "..." search starts here: >> #include <...> search starts here: >> . >> 32 >> ../../llvm-gcc4-2.0.source/gcc >> ../../llvm-gcc4-2.0.source/gcc/../include >> ../../llvm-gcc4-2.0.source/gcc/../libcpp/include >> /home/warren/llvm/llvm-2.0/include >> /home/warren/llvm/obj//include >> /home/warren/llvm-gcc/obj/gcc/include >> /usr/local/include >> /usr/include >> End of search list. >> GNU C version 4.0.1 LLVM (Apple Computer, Inc. build 2.0) >> (x86_64-unknown-linux-gnu) >> compiled by GNU C version 4.0.2 20050901 (prerelease) (SUSE >> Linux). >> GGC heuristics: --param ggc-min-expand=100 --param ggc-min- >> heapsize=131072 >> Warning: Generation of 64-bit code for a 32-bit processor requested. >> Warning: 64-bit processors all have at least SSE2. >> Compiler executable checksum: efa2a522e5a08a9a5e39009754b845ec >> as --traditional-format -V -Qy --32 -o 32/crtbegin.o /tmp/ccBy56Wo.s >> GNU assembler version 2.16.91.0.2 (x86_64-suse-linux) using BFD >> version >> 2.16.91.0.2 20050720 (SuSE Linux) >> /tmp/ccBy56Wo.s: Assembler messages: >> /tmp/ccBy56Wo.s:15: Error: bad register name `%rsp' >> /tmp/ccBy56Wo.s:16: Error: bad register name `%rbp' >> /tmp/ccBy56Wo.s:17: Error: bad register name `%rsp' >> /tmp/ccBy56Wo.s:18: Error: `completed.4705(%rip)' is not a valid >> base/index expression >> /tmp/ccBy56Wo.s:21: Error: `p.4704(%rip)' is not a valid base/index >> expression >> /tmp/ccBy56Wo.s:22: Error: bad register name `%rax)' >> /tmp/ccBy56Wo.s:23: Error: bad register name `%rax' >> /tmp/ccBy56Wo.s:26: Error: `p.4704(%rip)' is not a valid base/index >> expression >> /tmp/ccBy56Wo.s:27: Error: bad register name `%rax' >> /tmp/ccBy56Wo.s:28: Error: `p.4704(%rip)' is not a valid base/index >> expression >> /tmp/ccBy56Wo.s:29: Error: bad register name `%rax)' >> /tmp/ccBy56Wo.s:30: Error: bad register name `%rax' >> /tmp/ccBy56Wo.s:33: Error: `completed.4705(%rip)' is not a valid >> base/index expression >> /tmp/ccBy56Wo.s:34: Error: bad register name `%rbp' >> /tmp/ccBy56Wo.s:35: Error: bad register name `%rbp' >> /tmp/ccBy56Wo.s:38: Error: bad register name `%rbp' >> /tmp/ccBy56Wo.s:39: Error: bad register name `%rbp' >> /tmp/ccBy56Wo.s:47: Error: bad register name `%rsp' >> /tmp/ccBy56Wo.s:48: Error: bad register name `%rbp' >> /tmp/ccBy56Wo.s:49: Error: bad register name `%rsp' >> /tmp/ccBy56Wo.s:50: Error: `__JCR_LIST__(%rip)' is not a valid >> base/index expression >> /tmp/ccBy56Wo.s:53: Error: `_Jv_RegisterClasses(%rip)' is not a valid >> base/index expression >> /tmp/ccBy56Wo.s:55: Error: bad register name `%rax' >> /tmp/ccBy56Wo.s:58: Error: `__JCR_LIST__(%rip)' is not a valid >> base/index expression >> /tmp/ccBy56Wo.s:59: Error: bad register name `%rax' >> /tmp/ccBy56Wo.s:60: Error: bad register name `%rbp' >> /tmp/ccBy56Wo.s:61: Error: bad register name `%rbp' >> /tmp/ccBy56Wo.s:64: Error: bad register name `%rbp' >> /tmp/ccBy56Wo.s:65: Error: bad register name `%rbp' >> >> # Start of file scope inline assembly >> .section .fini >> call __do_global_dtors_aux >> .text >> .section .init >> call frame_dummy >> .text >> # End of file scope inline assembly >> >> >> .text >> .align 16 >> .type __do_global_dtors_aux, at function >> __do_global_dtors_aux: >> subq $8, %rsp >> movq %rbp, (%rsp) >> movq %rsp, %rbp >> cmpb $0, completed.4705(%rip) >> jne .LBB1_4 #UnifiedReturnBlock >> .LBB1_1: #bb9.preheader >> movq p.4704(%rip), %rax >> movq (%rax), %rax >> cmpq $0, %rax >> je .LBB1_3 #bb16 >> .LBB1_2: #bb >> addq $4, p.4704(%rip) >> call *%rax >> movq p.4704(%rip), %rax >> movq (%rax), %rax >> cmpq $0, %rax >> jne .LBB1_2 #bb >> .LBB1_3: #bb16 >> movb $1, completed.4705(%rip) >> movq %rbp, %rsp >> popq %rbp >> ret >> .LBB1_4: #UnifiedReturnBlock >> movq %rbp, %rsp >> popq %rbp >> ret >> .size __do_global_dtors_aux, .-__do_global_dtors_aux >> >> >> .align 16 >> .type frame_dummy, at function >> frame_dummy: >> subq $8, %rsp >> movq %rbp, (%rsp) >> movq %rsp, %rbp >> cmpq $0, __JCR_LIST__(%rip) >> je .LBB2_3 #UnifiedReturnBlock >> .LBB2_1: #cond_true >> leaq _Jv_RegisterClasses(%rip), %rax >> >> cmpq $0, %rax >> je .LBB2_3 #UnifiedReturnBlock >> .LBB2_2: #cond_true10 >> leaq __JCR_LIST__(%rip), %rdi >> call *%rax >> movq %rbp, %rsp >> popq %rbp >> ret >> .LBB2_3: #UnifiedReturnBlock >> movq %rbp, %rsp >> popq %rbp >> ret >> .size frame_dummy, .-frame_dummy >> .type __CTOR_LIST__, at object >> .section .ctors,"aw", at progbits >> .align 8 >> __CTOR_LIST__: # __CTOR_LIST__ >> .size __CTOR_LIST__, 8 >> .quad 4294967295 >> >> .type __DTOR_LIST__, at object >> .section .dtors,"aw", at progbits >> .align 8 >> __DTOR_LIST__: # __DTOR_LIST__ >> .size __DTOR_LIST__, 8 >> .quad 4294967295 >> >> .type __JCR_LIST__, at object >> .section .jcr >> .align 8 >> __JCR_LIST__: # __JCR_LIST__ >> .size __JCR_LIST__, 0 >> >> .hidden __dso_handle >> .type __dso_handle, at object >> .globl __dso_handle >> .data >> .align 8 >> __dso_handle: # __dso_handle >> .size __dso_handle, 8 >> .zero 8 >> >> .type p.4704, at object >> .align 8 >> p.4704: # p.4704 >> .size p.4704, 8 >> .quad (__DTOR_LIST__) + 8 >> >> .type completed.4705, at object >> .local completed.4705 >> .comm completed.4705,1,1 # completed.4705 >> .weak _Jv_RegisterClasses >> >> .ident "GCC: (GNU) 4.0.1 LLVM (Apple Computer, Inc. build 2.0)" >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From warren.armstrong at anu.edu.au Sun May 27 08:24:48 2007 From: warren.armstrong at anu.edu.au (Warren Armstrong) Date: Sun, 27 May 2007 23:24:48 +1000 Subject: [LLVMdev] Problems compiling llvm-gcc4 frontend on x86_64 In-Reply-To: References: <46567583.6060405@anu.edu.au> <342D09D4-4BA4-4E3E-B049-EF276FD3C570@gmail.com> Message-ID: <465986A0.70803@anu.edu.au> Hi Ferad, Yes, that worked. Thanks! Cheers, Warren Ferad Zyulkyarov wrote: > Hi Warren, > you can try to configure with the following > > export CFLAGS="-m64" > export LDFLAGS="-L/usr/lib64" > > LLVM: > ../src/configure --prefix=`pwd`../install --enable-optimized --enable-jit > --enable-targets=host-only > make > > LLVM-GCC: > ../llvm-gcc4-2.0.source/configure --prefix=`pwd`../install > --program-prefix=llvm- --enable-llvm=/home/warren/llvm/obj/ > --enable-languages=c,c++ --disable-shared --disable-multilib > > make > > Sometimes the gcc you use to compile matters. I wasn't able to compile with > 4.1.* for example. I use 4.0.4 right now. > > Regards, > Ferad Zyulkyarov > > > On 5/26/07, Bill Wendling wrote: >> >> Hi Warren, >> >> You have the -m32 flag set, but it's still giving you this: >> >> > Warning: Generation of 64-bit code for a 32-bit processor requested. >> > Warning: 64-bit processors all have at least SSE2. >> >> But are you sure you want to compile the LLVM-GCC source? You should >> use the binaries unless absolutely necessary. >> >> -bw >> >> On May 24, 2007, at 10:34 PM, Warren Armstrong wrote: >> >> > Hi all, >> > >> > I've run into problems compiling the llvm-gcc frontend on x86_64. >> > Is this >> > not supported, or am I making an error somewhere? >> > >> > The procedure I followed was: >> > >> > 1. Download LLVM 2.0 source as a tarball (from a few days ago, during >> > the testing phase). >> > 2. Download the llvm-gcc4 source today, as a tarball. >> > 3. Extract both. >> > >> > 4. Configure LLVM as: ../src/configure --prefix=`pwd`../install >> > --enable-optimized --enable-jit --enable-targets=host-only >> > (There is no llvm-gcc in the path) >> > 5. make ENABLE_OPTIMIZED=1 >> > >> > 6. Configure the frontend as: >> > ../llvm-gcc4-2.0.source/configure --prefix=`pwd`../install >> > --program-prefix=llvm- --enable-llvm=/home/warren/llvm/obj/ >> > --enable-languages=c,c++ --disable-shared >> > >> > 7. make LLVM_VERSION_INFO=2.0 >> > >> > This produced errors from the assembler. I reran the failing command >> > with -v, and got the output below. >> > I then changed the command to use -S instead of -c, the resulting >> > assembler is attached. >> > >> > Any advice gratefully received. >> > >> > Cheers, >> > Warren >> > >> > -------------- >> > >> > Failing command: >> > >> > >> > warren at sunnyvale:~/llvm-gcc/obj/gcc> /home/warren/llvm-gcc/obj/gcc/ >> > xgcc >> > -v -B/home/warren/llvm-gcc/obj/gcc/ >> > -B/home/warren/llvm-gcc/obj../install/x86_64-unknown-linux-gnu/bin/ >> > -B/home/warren/llvm-gcc/obj../install/x86_64-unknown-linux-gnu/lib/ >> > -isystem >> > /home/warren/llvm-gcc/obj../install/x86_64-unknown-linux-gnu/include >> > -isystem >> > /home/warren/llvm-gcc/obj../install/x86_64-unknown-linux-gnu/sys- >> > include >> > -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes >> > -Wmissing-prototypes -Wold-style-definition -isystem ./include -I. >> > -I32 -I../../llvm-gcc4-2.0.source/gcc >> > -I../../llvm-gcc4-2.0.source/gcc/32 >> > -I../../llvm-gcc4-2.0.source/gcc/../include >> > -I../../llvm-gcc4-2.0.source/gcc/../libcpp/include >> > -I/home/warren/llvm/llvm-2.0/include -I/home/warren/llvm/obj//include >> > -m32 -g0 -finhibit-size-directive -fno-inline-functions -fno- >> > exceptions >> > -fno-zero-initialized-in-bss -fno-unit-at-a-time -fno-omit-frame- >> > pointer >> > -fno-asynchronous-unwind-tables -c >> > ../../llvm-gcc4-2.0.source/gcc/crtstuff.c -DCRT_BEGIN -o 32/ >> > crtbegin.o >> > Reading specs from /home/warren/llvm-gcc/obj/gcc/specs >> > Target: x86_64-unknown-linux-gnu >> > Configured with: ../llvm-gcc4-2.0.source/configure >> > --prefix=/home/warren/llvm-gcc/obj../install --program-prefix=llvm- >> > --enable-llvm=/home/warren/llvm/obj/ --enable-languages=c,c++ >> > --disable-shared >> > Thread model: posix >> > gcc version 4.0.1 LLVM (Apple Computer, Inc. build 2.0) >> > /home/warren/llvm-gcc/obj/gcc/cc1 -quiet -v -I. -I32 >> > -I../../llvm-gcc4-2.0.source/gcc -I../../llvm-gcc4-2.0.source/gcc/32 >> > -I../../llvm-gcc4-2.0.source/gcc/../include >> > -I../../llvm-gcc4-2.0.source/gcc/../libcpp/include >> > -I/home/warren/llvm/llvm-2.0/include -I/home/warren/llvm/obj//include >> > -iprefix >> > /home/warren/llvm-gcc/obj/gcc/../lib/gcc/x86_64-unknown-linux-gnu/ >> > 4.0.1/ >> > -isystem /home/warren/llvm-gcc/obj/gcc/include -DIN_GCC -DCRT_BEGIN >> > -isystem >> > /home/warren/llvm-gcc/obj../install/x86_64-unknown-linux-gnu/include >> > -isystem >> > /home/warren/llvm-gcc/obj../install/x86_64-unknown-linux-gnu/sys- >> > include >> > -isystem ./include ../../llvm-gcc4-2.0.source/gcc/crtstuff.c -quiet >> > -dumpbase crtstuff.c -m32 -mtune=generic -auxbase-strip 32/crtbegin.o >> > -g0 -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes >> > -Wmissing-prototypes -Wold-style-definition -version >> > -finhibit-size-directive -fno-inline-functions -fno-exceptions >> > -fno-zero-initialized-in-bss -fno-unit-at-a-time -fno-omit-frame- >> > pointer >> > -fno-asynchronous-unwind-tables -o /tmp/ccBy56Wo.s >> > ignoring nonexistent directory >> > "/home/warren/llvm-gcc/obj../install/x86_64-unknown-linux-gnu/include" >> > ignoring nonexistent directory >> > "/home/warren/llvm-gcc/obj../install/x86_64-unknown-linux-gnu/sys- >> > include" >> > ignoring duplicate directory "./include" >> > ignoring nonexistent directory >> > "/home/warren/llvm-gcc/obj/gcc/../lib/gcc/x86_64-unknown-linux-gnu/ >> > 4.0.1/include" >> > ignoring nonexistent directory >> > "/home/warren/llvm-gcc/obj/gcc/../lib/gcc/x86_64-unknown-linux-gnu/ >> > 4.0.1/../../../../x86_64-unknown-linux-gnu/include" >> > ignoring nonexistent directory "/home/warren/llvm-gcc/obj../install/ >> > include" >> > ignoring nonexistent directory >> > "/home/warren/llvm-gcc/obj../install/lib/gcc/x86_64-unknown-linux- >> > gnu/4.0.1/include" >> > ignoring nonexistent directory >> > "/home/warren/llvm-gcc/obj../install/x86_64-unknown-linux-gnu/include" >> > ignoring nonexistent directory "../../llvm-gcc4-2.0.source/gcc/32" >> > #include "..." search starts here: >> > #include <...> search starts here: >> > . >> > 32 >> > ../../llvm-gcc4-2.0.source/gcc >> > ../../llvm-gcc4-2.0.source/gcc/../include >> > ../../llvm-gcc4-2.0.source/gcc/../libcpp/include >> > /home/warren/llvm/llvm-2.0/include >> > /home/warren/llvm/obj//include >> > /home/warren/llvm-gcc/obj/gcc/include >> > /usr/local/include >> > /usr/include >> > End of search list. >> > GNU C version 4.0.1 LLVM (Apple Computer, Inc. build 2.0) >> > (x86_64-unknown-linux-gnu) >> > compiled by GNU C version 4.0.2 20050901 (prerelease) (SUSE >> > Linux). >> > GGC heuristics: --param ggc-min-expand=100 --param ggc-min- >> > heapsize=131072 >> > Warning: Generation of 64-bit code for a 32-bit processor requested. >> > Warning: 64-bit processors all have at least SSE2. >> > Compiler executable checksum: efa2a522e5a08a9a5e39009754b845ec >> > as --traditional-format -V -Qy --32 -o 32/crtbegin.o /tmp/ccBy56Wo.s >> > GNU assembler version 2.16.91.0.2 (x86_64-suse-linux) using BFD >> > version >> > 2.16.91.0.2 20050720 (SuSE Linux) >> > /tmp/ccBy56Wo.s: Assembler messages: >> > /tmp/ccBy56Wo.s:15: Error: bad register name `%rsp' >> > /tmp/ccBy56Wo.s:16: Error: bad register name `%rbp' >> > /tmp/ccBy56Wo.s:17: Error: bad register name `%rsp' >> > /tmp/ccBy56Wo.s:18: Error: `completed.4705(%rip)' is not a valid >> > base/index expression >> > /tmp/ccBy56Wo.s:21: Error: `p.4704(%rip)' is not a valid base/index >> > expression >> > /tmp/ccBy56Wo.s:22: Error: bad register name `%rax)' >> > /tmp/ccBy56Wo.s:23: Error: bad register name `%rax' >> > /tmp/ccBy56Wo.s:26: Error: `p.4704(%rip)' is not a valid base/index >> > expression >> > /tmp/ccBy56Wo.s:27: Error: bad register name `%rax' >> > /tmp/ccBy56Wo.s:28: Error: `p.4704(%rip)' is not a valid base/index >> > expression >> > /tmp/ccBy56Wo.s:29: Error: bad register name `%rax)' >> > /tmp/ccBy56Wo.s:30: Error: bad register name `%rax' >> > /tmp/ccBy56Wo.s:33: Error: `completed.4705(%rip)' is not a valid >> > base/index expression >> > /tmp/ccBy56Wo.s:34: Error: bad register name `%rbp' >> > /tmp/ccBy56Wo.s:35: Error: bad register name `%rbp' >> > /tmp/ccBy56Wo.s:38: Error: bad register name `%rbp' >> > /tmp/ccBy56Wo.s:39: Error: bad register name `%rbp' >> > /tmp/ccBy56Wo.s:47: Error: bad register name `%rsp' >> > /tmp/ccBy56Wo.s:48: Error: bad register name `%rbp' >> > /tmp/ccBy56Wo.s:49: Error: bad register name `%rsp' >> > /tmp/ccBy56Wo.s:50: Error: `__JCR_LIST__(%rip)' is not a valid >> > base/index expression >> > /tmp/ccBy56Wo.s:53: Error: `_Jv_RegisterClasses(%rip)' is not a valid >> > base/index expression >> > /tmp/ccBy56Wo.s:55: Error: bad register name `%rax' >> > /tmp/ccBy56Wo.s:58: Error: `__JCR_LIST__(%rip)' is not a valid >> > base/index expression >> > /tmp/ccBy56Wo.s:59: Error: bad register name `%rax' >> > /tmp/ccBy56Wo.s:60: Error: bad register name `%rbp' >> > /tmp/ccBy56Wo.s:61: Error: bad register name `%rbp' >> > /tmp/ccBy56Wo.s:64: Error: bad register name `%rbp' >> > /tmp/ccBy56Wo.s:65: Error: bad register name `%rbp' >> > >> > # Start of file scope inline assembly >> > .section .fini >> > call __do_global_dtors_aux >> > .text >> > .section .init >> > call frame_dummy >> > .text >> > # End of file scope inline assembly >> > >> > >> > .text >> > .align 16 >> > .type __do_global_dtors_aux, at function >> > __do_global_dtors_aux: >> > subq $8, %rsp >> > movq %rbp, (%rsp) >> > movq %rsp, %rbp >> > cmpb $0, completed.4705(%rip) >> > jne .LBB1_4 #UnifiedReturnBlock >> > .LBB1_1: #bb9.preheader >> > movq p.4704(%rip), %rax >> > movq (%rax), %rax >> > cmpq $0, %rax >> > je .LBB1_3 #bb16 >> > .LBB1_2: #bb >> > addq $4, p.4704(%rip) >> > call *%rax >> > movq p.4704(%rip), %rax >> > movq (%rax), %rax >> > cmpq $0, %rax >> > jne .LBB1_2 #bb >> > .LBB1_3: #bb16 >> > movb $1, completed.4705(%rip) >> > movq %rbp, %rsp >> > popq %rbp >> > ret >> > .LBB1_4: #UnifiedReturnBlock >> > movq %rbp, %rsp >> > popq %rbp >> > ret >> > .size __do_global_dtors_aux, .-__do_global_dtors_aux >> > >> > >> > .align 16 >> > .type frame_dummy, at function >> > frame_dummy: >> > subq $8, %rsp >> > movq %rbp, (%rsp) >> > movq %rsp, %rbp >> > cmpq $0, __JCR_LIST__(%rip) >> > je .LBB2_3 #UnifiedReturnBlock >> > .LBB2_1: #cond_true >> > leaq _Jv_RegisterClasses(%rip), %rax >> > >> > cmpq $0, %rax >> > je .LBB2_3 #UnifiedReturnBlock >> > .LBB2_2: #cond_true10 >> > leaq __JCR_LIST__(%rip), %rdi >> > call *%rax >> > movq %rbp, %rsp >> > popq %rbp >> > ret >> > .LBB2_3: #UnifiedReturnBlock >> > movq %rbp, %rsp >> > popq %rbp >> > ret >> > .size frame_dummy, .-frame_dummy >> > .type __CTOR_LIST__, at object >> > .section .ctors,"aw", at progbits >> > .align 8 >> > __CTOR_LIST__: # __CTOR_LIST__ >> > .size __CTOR_LIST__, 8 >> > .quad 4294967295 >> > >> > .type __DTOR_LIST__, at object >> > .section .dtors,"aw", at progbits >> > .align 8 >> > __DTOR_LIST__: # __DTOR_LIST__ >> > .size __DTOR_LIST__, 8 >> > .quad 4294967295 >> > >> > .type __JCR_LIST__, at object >> > .section .jcr >> > .align 8 >> > __JCR_LIST__: # __JCR_LIST__ >> > .size __JCR_LIST__, 0 >> > >> > .hidden __dso_handle >> > .type __dso_handle, at object >> > .globl __dso_handle >> > .data >> > .align 8 >> > __dso_handle: # __dso_handle >> > .size __dso_handle, 8 >> > .zero 8 >> > >> > .type p.4704, at object >> > .align 8 >> > p.4704: # p.4704 >> > .size p.4704, 8 >> > .quad (__DTOR_LIST__) + 8 >> > >> > .type completed.4705, at object >> > .local completed.4705 >> > .comm completed.4705,1,1 # completed.4705 >> > .weak _Jv_RegisterClasses >> > >> > .ident "GCC: (GNU) 4.0.1 LLVM (Apple Computer, Inc. build 2.0)" >> > _______________________________________________ >> > LLVM Developers mailing list >> > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > > > ------------------------------------------------------------------------ > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From sabre at nondot.org Sun May 27 13:01:28 2007 From: sabre at nondot.org (Chris Lattner) Date: Sun, 27 May 2007 11:01:28 -0700 (PDT) Subject: [LLVMdev] New LLVMBuilder api Message-ID: I just checked in a new LLVMBuilder class into llvm/Support/LLVMBuilder.h, and switched llvm-gcc over to use it. This class is based on feedback Tom Tromey gave on LLVM way back here: http://lists.cs.uiuc.edu/pipermail/llvmdev/2006-April/005581.html Basically, when creating a frontend, you end up creating a lot of instructions. This has three suboptimal aspects to it: 1. The constructors for the instructions all must be passed a place to insert the instructions into. Because the instructions often take a long list of arguments, this is nontrivial can can cause errors (Tom hit a problem with Alloca, for example). 2. The instruction ctors all default construct an std::string. In practice, this is a very modest overhead, but if it isn't needed, it shouldn't happen. 3. Some of the construction APIs are very verbose, my "favorite" being BinaryOperator::createAdd and friends. The new API separates the idea of what to construct from where to insert it. In particular, when you create an LLVMBuilder object, you can tell it where to insert all subsequently created instructions. This means you end up writing code like this: LLVMBuilder B; B.SetInsertPoint(); Value *V1 = B.CreateAdd(a, b, "tmp"); Value *V2 = B.CreateMul(V1, c, "whatever"); Value *V3 = B.CreateCall(FnPtr, V1, V2); ... The name strings are c strings, are always at the end of the argument list, and are always optional. This API is simple and consistent, which makes it easy to understand. It would also be really easy to build a C api for it, if someone is interested (hint hint :), -Chris -- http://nondot.org/sabre/ http://llvm.org/ From angray at beeb.net Sun May 27 17:03:11 2007 From: angray at beeb.net (Aaron Gray) Date: Sun, 27 May 2007 23:03:11 +0100 Subject: [LLVMdev] New LLVMBuilder api References: Message-ID: <00db01c7a0aa$d2cc5740$0200a8c0@AMD2500> > I just checked in a new LLVMBuilder class into llvm/Support/LLVMBuilder.h, It does not seem to be on the LLVM cvsweb, is that still showing 1.9 or 2.0 and not cvs ? Aaron From sabre at nondot.org Sun May 27 18:53:27 2007 From: sabre at nondot.org (Chris Lattner) Date: Sun, 27 May 2007 16:53:27 -0700 (PDT) Subject: [LLVMdev] New LLVMBuilder api In-Reply-To: <00db01c7a0aa$d2cc5740$0200a8c0@AMD2500> References: <00db01c7a0aa$d2cc5740$0200a8c0@AMD2500> Message-ID: On Sun, 27 May 2007, Aaron Gray wrote: >> I just checked in a new LLVMBuilder class into llvm/Support/LLVMBuilder.h, > It does not seem to be on the LLVM cvsweb, is that still showing 1.9 or 2.0 > and not cvs ? It is there: http://llvm.org/cvsweb/cvsweb.cgi/llvm/include/llvm/Support/LLVMBuilder.h?rev=HEAD&content-type=text/x-cvsweb-markup -Chris -- http://nondot.org/sabre/ http://llvm.org/ From angray at beeb.net Sun May 27 17:11:48 2007 From: angray at beeb.net (Aaron Gray) Date: Sun, 27 May 2007 23:11:48 +0100 Subject: [LLVMdev] New LLVMBuilder api References: <00db01c7a0aa$d2cc5740$0200a8c0@AMD2500> Message-ID: <00e001c7a0ac$0951e6d0$0200a8c0@AMD2500> > On Sun, 27 May 2007, Aaron Gray wrote: >>> I just checked in a new LLVMBuilder class into >>> llvm/Support/LLVMBuilder.h, >> It does not seem to be on the LLVM cvsweb, is that still showing 1.9 or >> 2.0 >> and not cvs ? > > It is there: > http://llvm.org/cvsweb/cvsweb.cgi/llvm/include/llvm/Support/LLVMBuilder.h?rev=HEAD&content-type=text/x-cvsweb-markup Ah, right, sorry, not looking properly. This is a tiny bit like .NET, but that uses emit rather than CreateX. How did the meeting go, have heard no news on the mailing list. Aaron From sabre at nondot.org Sun May 27 19:03:28 2007 From: sabre at nondot.org (Chris Lattner) Date: Sun, 27 May 2007 17:03:28 -0700 (PDT) Subject: [LLVMdev] New LLVMBuilder api In-Reply-To: <00e001c7a0ac$0951e6d0$0200a8c0@AMD2500> References: <00db01c7a0aa$d2cc5740$0200a8c0@AMD2500> <00e001c7a0ac$0951e6d0$0200a8c0@AMD2500> Message-ID: On Sun, 27 May 2007, Aaron Gray wrote: > How did the meeting go, have heard no news on the mailing list. Some news here: http://lists.cs.uiuc.edu/pipermail/llvmdev/2007-May/009187.html I imagine that people are traveling back home. The videos turned out great, we should have them online in a week or two worst case. Other attendees are welcome to contribute their impressions :) -Chris -- http://nondot.org/sabre/ http://llvm.org/ From tonic at nondot.org Sun May 27 19:03:57 2007 From: tonic at nondot.org (Tanya M. Lattner) Date: Sun, 27 May 2007 17:03:57 -0700 (PDT) Subject: [LLVMdev] New LLVMBuilder api In-Reply-To: <00e001c7a0ac$0951e6d0$0200a8c0@AMD2500> References: <00db01c7a0aa$d2cc5740$0200a8c0@AMD2500> <00e001c7a0ac$0951e6d0$0200a8c0@AMD2500> Message-ID: > How did the meeting go, have heard no news on the mailing list. http://lists.cs.uiuc.edu/pipermail/llvmdev/2007-May/009187.html -Tanya From angray at beeb.net Sun May 27 17:41:25 2007 From: angray at beeb.net (Aaron Gray) Date: Sun, 27 May 2007 23:41:25 +0100 Subject: [LLVMdev] New LLVMBuilder api References: <00db01c7a0aa$d2cc5740$0200a8c0@AMD2500> <00e001c7a0ac$0951e6d0$0200a8c0@AMD2500> Message-ID: <011a01c7a0b0$2affbd80$0200a8c0@AMD2500> >> On Sun, 27 May 2007, Aaron Gray wrote: >>>> I just checked in a new LLVMBuilder class into >>>> llvm/Support/LLVMBuilder.h, >>> It does not seem to be on the LLVM cvsweb, is that still showing 1.9 or >>> 2.0 >>> and not cvs ? >> >> It is there: >> http://llvm.org/cvsweb/cvsweb.cgi/llvm/include/llvm/Support/LLVMBuilder.h?rev=HEAD&content-type=text/x-cvsweb-markup > > Ah, right, sorry, not looking properly. > > This is a tiny bit like .NET, but that uses emit rather than CreateX. CreateMalloc and CreateAlloca should not the ArraySize be set to (a) 1 as default argument ? Aaron From sabre at nondot.org Sun May 27 21:57:49 2007 From: sabre at nondot.org (Chris Lattner) Date: Sun, 27 May 2007 19:57:49 -0700 (PDT) Subject: [LLVMdev] New LLVMBuilder api In-Reply-To: <011a01c7a0b0$2affbd80$0200a8c0@AMD2500> References: <00db01c7a0aa$d2cc5740$0200a8c0@AMD2500> <00e001c7a0ac$0951e6d0$0200a8c0@AMD2500> <011a01c7a0b0$2affbd80$0200a8c0@AMD2500> Message-ID: On Sun, 27 May 2007, Aaron Gray wrote: >> This is a tiny bit like .NET, but that uses emit rather than CreateX. > > CreateMalloc and CreateAlloca should not the ArraySize be set to (a) 1 as > default argument ? Yes, they are. -Chris -- http://nondot.org/sabre/ http://llvm.org/ From sabre at nondot.org Sun May 27 21:59:56 2007 From: sabre at nondot.org (Chris Lattner) Date: Sun, 27 May 2007 19:59:56 -0700 (PDT) Subject: [LLVMdev] [llvm-announce] LLVM 2.0 Release In-Reply-To: <46596EE2.8040603@laposte.net> References: <46596EE2.8040603@laposte.net> Message-ID: On Sun, 27 May 2007, Christophe Avoinne wrote: > On 23/05/2007 22:05:48, Chris Lattner (sabre at nondot.org) wrote: > > LLVM 2.0 is done! Download it here: http://llvm.org/releases/ or view > > the release notes: http://llvm.org/releases/2.0/docs/ReleaseNotes.html > > > > Hello Chris. > > Your project sounds quite exciting and I may be interested to use it instead > of gcc. > > Well, let's me explain why I'm interested in this project : > > I have a PlayStation Portable and like to develop several projects using > all of its potential. > > PSP has two Allegrex cpus : SC (system control) and ME (Media Engine). > Both are designed with a MIPS 2 core plus a dozen instructions borrowed from > MIPS4. > Both also have a standard FPU coprocessor. > But only SC processor has a second coprocessor called VFPU which allows > matrix and vector computations. > > Actually, gcc doesn't handle VFPU at all (i'm speaking about the compiler, > not the assembler). > > I tried to add the necessary things to allow gcc to handle them but I have > only a half success because of the way gcc handles registers and a few other > messing things. > > So i'm looking for an alternative : llvm-gcc. Ok. > First, what is VFPU : > > it is a great coprocessor which allows us to handle up to 128 32-bit float > registers as a scalar or as a vector of two, three or four elements or as a > square matrix of 4, 9 or 16 elements. > > - a scalar : S000 = [$0], S001, [$1], S002 = [$2], S003 = [$3], S100 = [$4], > ..., S010 = [$32], ..., S020 = [$64], ..., S733 = [$127] > - a column : C000.p = [S000, S010], C020.p = [S020, S030], ..., C000.t = > [S000, S010, S020], C010.t = [S010, S020, S030], ..., C000.q = [S000, S010, > S020, S030] > - a row : R000.p = [S000, S001], R002.p = [S002, S003], R000.t = [S000, S001, > S002], R001.t = [S001, S002, S003], R000.q = [S000, S001, S002, S003] > - a matrix : M000.p = [R000.p, R010.p], M020.p = [R020.p, R030.p], ..., > M000.t = [R000.t, R010.t, R020.t], ..., M000.q = [R000.q, R010.q, R020.q, > R030q] > - a transposed matrix : E000.p = [C000.p, C001.p], M020.p = [R020.p, R030.p], > ..., M000.t = [R000.t, R010.t, R020.t], ..., M000.q = [R000.q, R010.q, > R020.q, R030q] > > (NOTE : <#m><#r><#c>. : t = S (scalar)/C (column)/R (row)/M (matrix)/E > (transposed matrix), #m = matrix, #r = row, #c = column, s = p (2d vector), t > (3d vector), q (4d vector)) > > now, if you want just a 3d dot product, just issue this instruction for > instance : vdot.t S000.s, C100.t, C110.t > or a matrix product : vmmul.q M000.q, M100.q, E200.q > > As you can see, that VFPU has a great potential but, alas, it is not very > well exploited by the open source psp-gcc. Ok. > Now, lets's speak about llvm-gcc. > > 1) Does a (uncompleted) MIPS target exist for llvm-gcc ? or must I create > one ? Bruno just submitted one, he's the right person to talk to. I have not had a chance to review the code, so it has not been committed yet, but it should be soon. > 2) Do you think that llvm-gcc can handle those combinaisons of registers : > 2.1) Can llvm-gcc handle vector float as a super-set of scalar registers ? > 2.2) Can llvm-gcc handle matrix float as a super-set of vector float ? LLVM has good support for vectors, if you treat matrices as large vectors, you should have no problem. > 3) Can llvm-gcc vectorize float operations ? llvm-gcc supports explicitly vectorized code, but we have no autovectorization pass yet. -Chris -- http://nondot.org/sabre/ http://llvm.org/ From armbox at gmail.com Sun May 27 23:39:22 2007 From: armbox at gmail.com (quho) Date: Mon, 28 May 2007 13:39:22 +0900 Subject: [LLVMdev] Problem in llvm gcc back-end Message-ID: HI, While I testing some code, I found some problem on Union handling. I've wrte following test code, and it has union assignment. The code's output is from pointerToUnion: chars mystring, length 64 from original: chars mystring, length 8000 It's caused by second char member(charlength) of LongestMember. For union assignment, llvm-backend seems generates assigning each member of largest union member. (I've checked it on llvm assembly level..) But sometimes there is padding between members and it's different for members. So in my opinion you should handle union assignment as pseudo array of word(or byte). (it's same for argument passing..) ===================================================== #include struct MyString { char *chars; int length; }; struct LongestMember { char *chars; char charlength; int empty1; int empty2; }; typedef union { MyString string; LongestMember mt; } UnionType; int main() { UnionType original; UnionType *pointerToUnion; UnionType buffer; pointerToUnion = &buffer; original.string.chars = "mystring"; original.string.length = 8000; *pointerToUnion = original; printf("from pointerToUnion: chars %s, length %d\n", pointerToUnion->string.chars, pointerToUnion->string.length); printf("from original: chars %s, length %d\n", original.string.chars, original.string.length); } ===================================================== Thanks, Quho. From lee225 at uiuc.edu Mon May 28 00:11:10 2007 From: lee225 at uiuc.edu (Seung Jae Lee) Date: Mon, 28 May 2007 00:11:10 -0500 (CDT) Subject: [LLVMdev] Usage of llvmc Message-ID: <20070528001110.AQI03115@expms2.cites.uiuc.edu> Hello, guys. I've tried to use llvmc to test optimization options but wasn't successful. Would you mind telling me what's wrong with this? ------------------------------------------------------------- $ llvmc chc_03.c -O3 -o chc_03 terminate called after throwing an instance of 'std::string' llvmc((anonymous namespace)::PrintStackTrace()+0x15)[0x8086091] /lib/tls/libc.so.6(abort+0xe9)[0x367199] /usr/lib/libstdc++.so.6(__gnu_cxx::__verbose_terminate_handler()+0xeb)[0x74e25b] /usr/lib/libstdc++.so.6[0x74bf71] /usr/lib/libstdc++.so.6[0x74bfa6] /usr/lib/libstdc++.so.6[0x74c0ef] llvmc(llvm::LLVMC_ConfigDataProvider::ReadConfigData(std::basic_string, std::allocator > const&)+0x849)[0x8066f65] [0x0] Aborted $ ------------------------------------------------------------- Forgive my ignorance. Thank you. Seung Jae Lee From sabre at nondot.org Mon May 28 02:08:47 2007 From: sabre at nondot.org (Chris Lattner) Date: Mon, 28 May 2007 00:08:47 -0700 (PDT) Subject: [LLVMdev] Usage of llvmc In-Reply-To: <20070528001110.AQI03115@expms2.cites.uiuc.edu> References: <20070528001110.AQI03115@expms2.cites.uiuc.edu> Message-ID: On Mon, 28 May 2007, Seung Jae Lee wrote: > Hello, guys. > I've tried to use llvmc to test optimization options but wasn't successful. > Would you mind telling me what's wrong with this? Hi, llvmc is experimental and isn't really supported. I'd suggest using llvm-gcc instead. -Chris > ------------------------------------------------------------- > $ llvmc chc_03.c -O3 -o chc_03 > terminate called after throwing an instance of 'std::string' > llvmc((anonymous namespace)::PrintStackTrace()+0x15)[0x8086091] > /lib/tls/libc.so.6(abort+0xe9)[0x367199] > /usr/lib/libstdc++.so.6(__gnu_cxx::__verbose_terminate_handler()+0xeb)[0x74e25b] > /usr/lib/libstdc++.so.6[0x74bf71] > /usr/lib/libstdc++.so.6[0x74bfa6] > /usr/lib/libstdc++.so.6[0x74c0ef] > llvmc(llvm::LLVMC_ConfigDataProvider::ReadConfigData(std::basic_string, std::allocator > const&)+0x849)[0x8066f65] > [0x0] > Aborted > $ > ------------------------------------------------------------- > Forgive my ignorance. > Thank you. > > Seung Jae Lee > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > -Chris -- http://nondot.org/sabre/ http://llvm.org/ From armbox at gmail.com Mon May 28 01:38:41 2007 From: armbox at gmail.com (quho) Date: Mon, 28 May 2007 15:38:41 +0900 Subject: [LLVMdev] Problem in llvm gcc back-end In-Reply-To: References: Message-ID: Hi, I'm sorry, I found it on bugzilla database.. http://llvm.org/bugs/show_bug.cgi?id=1421 And there was instruction for fix it. Thanks Quho 2007/5/28, quho : > HI, > > While I testing some code, I found some problem on Union handling. > > I've wrte following test code, and it has union assignment. > > The code's output is > > from pointerToUnion: chars mystring, length 64 > from original: chars mystring, length 8000 > > It's caused by second char member(charlength) of LongestMember. > > For union assignment, llvm-backend seems generates assigning each > member of largest union member. (I've checked it on llvm assembly > level..) > But sometimes there is padding between members and it's different for members. > > So in my opinion you should handle union assignment as pseudo array of > word(or byte). > (it's same for argument passing..) > > > ===================================================== > #include > > struct MyString { > char *chars; > int length; > }; > > struct LongestMember { > char *chars; > char charlength; > int empty1; > int empty2; > }; > > typedef union { > MyString string; > LongestMember mt; > } UnionType; > > > int main() { > UnionType original; > UnionType *pointerToUnion; > UnionType buffer; > > pointerToUnion = &buffer; > > original.string.chars = "mystring"; > original.string.length = 8000; > > *pointerToUnion = original; > > printf("from pointerToUnion: chars %s, length %d\n", > pointerToUnion->string.chars, pointerToUnion->string.length); > printf("from original: chars %s, length %d\n", > original.string.chars, original.string.length); > } > ===================================================== > > > Thanks, > Quho. > -- Armbox. From lee225 at uiuc.edu Mon May 28 02:25:16 2007 From: lee225 at uiuc.edu (Seung Jae Lee) Date: Mon, 28 May 2007 02:25:16 -0500 (CDT) Subject: [LLVMdev] Usage of llvmc Message-ID: <20070528022516.AQI11929@expms2.cites.uiuc.edu> Thank you so much for your reply, Chris. If so, can I ask you two things more? First, is there any way to have various optimizations on LLVM assembly such as -O options in llvmc? llvm-gcc doesn't seem to be working for these -O options... Second, I'm still not sure about difference between *.s and *.ll. LLVM assembly *.s file can be made from llvm-gcc -S. Another assembly *.ll file comes from just llvm-gcc. Is the difference between these two extensions on the optimized state? Thanks, Seung J. Lee ---- Original message ---- >Date: Mon, 28 May 2007 00:08:47 -0700 (PDT) >From: Chris Lattner >Subject: Re: [LLVMdev] Usage of llvmc >To: LLVM Developers Mailing List > >On Mon, 28 May 2007, Seung Jae Lee wrote: >> Hello, guys. >> I've tried to use llvmc to test optimization options but wasn't successful. >> Would you mind telling me what's wrong with this? > >Hi, llvmc is experimental and isn't really supported. I'd suggest using >llvm-gcc instead. > >-Chris > >> ------------------------------------------------------------- >> $ llvmc chc_03.c -O3 -o chc_03 >> terminate called after throwing an instance of 'std::string' >> llvmc((anonymous namespace)::PrintStackTrace()+0x15)[0x8086091] >> /lib/tls/libc.so.6(abort+0xe9)[0x367199] >> /usr/lib/libstdc++.so.6(__gnu_cxx::__verbose_terminate_handler()+0xeb)[0x74e25b] >> /usr/lib/libstdc++.so.6[0x74bf71] >> /usr/lib/libstdc++.so.6[0x74bfa6] >> /usr/lib/libstdc++.so.6[0x74c0ef] >> llvmc(llvm::LLVMC_ConfigDataProvider::ReadConfigData(std::basic_string, std::allocator > const&)+0x849)[0x8066f65] >> [0x0] >> Aborted >> $ >> ------------------------------------------------------------- >> Forgive my ignorance. >> Thank you. >> >> Seung Jae Lee >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > >-Chris > >-- >http://nondot.org/sabre/ >http://llvm.org/ >_______________________________________________ >LLVM Developers mailing list >LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From lee225 at uiuc.edu Mon May 28 02:31:45 2007 From: lee225 at uiuc.edu (Seung Jae Lee) Date: Mon, 28 May 2007 02:31:45 -0500 (CDT) Subject: [LLVMdev] Usage of llvmc (Sorry. Please disregard the right above.) Message-ID: <20070528023145.AQI12121@expms2.cites.uiuc.edu> Thank you so much for your reply, Chris. If so, can I ask you two things more? First, is there any way to have various optimizations on LLVM assembly such as -O options in llvmc? llvm-gcc doesn't seem to be working for these -O options... Second, I'm still not sure about difference between *.s and *.ll. LLVM assembly *.s file can be made from llvm-gcc with -S option. Another assembly *.ll file comes from just llvm-gcc and llvm-dis. Is the difference between these two extensions on the optimized state? Thanks, Seung J. Lee ---- Original message ---- >Date: Mon, 28 May 2007 00:08:47 -0700 (PDT) >From: Chris Lattner >Subject: Re: [LLVMdev] Usage of llvmc >To: LLVM Developers Mailing List > >On Mon, 28 May 2007, Seung Jae Lee wrote: >> Hello, guys. >> I've tried to use llvmc to test optimization options but wasn't successful. >> Would you mind telling me what's wrong with this? > >Hi, llvmc is experimental and isn't really supported. I'd suggest using >llvm-gcc instead. > >-Chris > >> ------------------------------------------------------------- >> $ llvmc chc_03.c -O3 -o chc_03 >> terminate called after throwing an instance of 'std::string' >> llvmc((anonymous namespace)::PrintStackTrace()+0x15)[0x8086091] >> /lib/tls/libc.so.6(abort+0xe9)[0x367199] >> /usr/lib/libstdc++.so.6(__gnu_cxx::__verbose_terminate_handler()+0xeb)[0x74e25b] >> /usr/lib/libstdc++.so.6[0x74bf71] >> /usr/lib/libstdc++.so.6[0x74bfa6] >> /usr/lib/libstdc++.so.6[0x74c0ef] >> llvmc(llvm::LLVMC_ConfigDataProvider::ReadConfigData(std::basic_string, std::allocator > const&)+0x849)[0x8066f65] >> [0x0] >> Aborted >> $ >> ------------------------------------------------------------- >> Forgive my ignorance. >> Thank you. >> >> Seung Jae Lee >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > >-Chris > >-- >http://nondot.org/sabre/ >http://llvm.org/ >_______________________________________________ >LLVM Developers mailing list >LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From sabre at nondot.org Mon May 28 04:22:16 2007 From: sabre at nondot.org (Chris Lattner) Date: Mon, 28 May 2007 02:22:16 -0700 (PDT) Subject: [LLVMdev] Usage of llvmc In-Reply-To: <20070528022516.AQI11929@expms2.cites.uiuc.edu> References: <20070528022516.AQI11929@expms2.cites.uiuc.edu> Message-ID: On Mon, 28 May 2007, Seung Jae Lee wrote: > Thank you so much for your reply, Chris. > If so, can I ask you two things more? > > First, is there any way to have various optimizations on LLVM assembly such as -O options in llvmc? > llvm-gcc doesn't seem to be working for these -O options... llvm-gcc accepts and responds to -O[01234s]. > Second, I'm still not sure about difference between *.s and *.ll. > LLVM assembly *.s file can be made from llvm-gcc -S. > Another assembly *.ll file comes from just llvm-gcc. > Is the difference between these two extensions on the optimized state? It sounds to me like you're using llvm-gcc3. Please upgrade to llvm 2.0 and llvm-gcc4. -Chris > Thanks, > Seung J. Lee > > ---- Original message ---- >> Date: Mon, 28 May 2007 00:08:47 -0700 (PDT) >> From: Chris Lattner >> Subject: Re: [LLVMdev] Usage of llvmc >> To: LLVM Developers Mailing List >> >> On Mon, 28 May 2007, Seung Jae Lee wrote: >>> Hello, guys. >>> I've tried to use llvmc to test optimization options but wasn't successful. >>> Would you mind telling me what's wrong with this? >> >> Hi, llvmc is experimental and isn't really supported. I'd suggest using >> llvm-gcc instead. >> >> -Chris >> >>> ------------------------------------------------------------- >>> $ llvmc chc_03.c -O3 -o chc_03 >>> terminate called after throwing an instance of 'std::string' >>> llvmc((anonymous namespace)::PrintStackTrace()+0x15)[0x8086091] >>> /lib/tls/libc.so.6(abort+0xe9)[0x367199] >>> /usr/lib/libstdc++.so.6(__gnu_cxx::__verbose_terminate_handler()+0xeb)[0x74e25b] >>> /usr/lib/libstdc++.so.6[0x74bf71] >>> /usr/lib/libstdc++.so.6[0x74bfa6] >>> /usr/lib/libstdc++.so.6[0x74c0ef] >>> llvmc(llvm::LLVMC_ConfigDataProvider::ReadConfigData(std::basic_string, std::allocator > const&)+0x849)[0x8066f65] >>> [0x0] >>> Aborted >>> $ >>> ------------------------------------------------------------- >>> Forgive my ignorance. >>> Thank you. >>> >>> Seung Jae Lee >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>> >> >> -Chris >> >> -- >> http://nondot.org/sabre/ >> http://llvm.org/ >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > -Chris -- http://nondot.org/sabre/ http://llvm.org/ From bram.adams at ugent.be Mon May 28 09:40:45 2007 From: bram.adams at ugent.be (Bram Adams) Date: Mon, 28 May 2007 16:40:45 +0200 Subject: [LLVMdev] Linking two external linkage GlobalValues In-Reply-To: References: <23EDA1A0-E658-4441-8BA8-D08DC252EAF0.SS1079SS@ugent.be> <1180104803.5117.95.camel@asl.dorms.spbu.ru> <603A38F2-0CAF-414D-8A49-BBC5461D2984@ugent.be> Message-ID: <6AE604E1-84C5-4E65-AD8D-3AB1D0C397E9@ugent.be> Hi, Op 27-mei-07, om 00:45 heeft Chris Lattner het volgende geschreven: > -fno-common is a performance win on some targets, but it disallows > merging > of global variables that are defined with no initializers (like your > example). Please remove -fno-common, if it builds correctly, then > it is > not an llvm bug. It was indeed the -fno-common which caused the problems, so it's not an LLVM bug. Kind regards, Bram Adams GH-SEL, INTEC, Ghent University (Belgium) From roncking at cox.net Mon May 28 07:21:09 2007 From: roncking at cox.net (ron king) Date: Mon, 28 May 2007 07:21:09 -0500 Subject: [LLVMdev] Generating code for java Message-ID: <465AC935.6090906@cox.net> Hi everyone, I wonder if anyone has developed a way for llvm to generate Jasmin assembler, which would allow creating java class files from C/C++ code? Regards, Ron King From scott.llvm at h4ck3r.net Mon May 28 18:17:41 2007 From: scott.llvm at h4ck3r.net (Scott Graham) Date: Mon, 28 May 2007 16:17:41 -0700 Subject: [LLVMdev] license file Message-ID: <84decce20705281617pb73b7f0r5d629ec607a8baf8@mail.gmail.com> Hi I noticed that http://llvm.org/releases/2.0/LICENSE.TXT pointed to by a variety of places on llvm.org does not exist. scott -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20070528/fed7abdc/attachment.html From lee225 at uiuc.edu Mon May 28 22:55:14 2007 From: lee225 at uiuc.edu (Seung Jae Lee) Date: Mon, 28 May 2007 22:55:14 -0500 (CDT) Subject: [LLVMdev] LLVM website down today? Message-ID: <20070528225514.AQI70590@expms2.cites.uiuc.edu> Hello. I just wonder if LLVM website is down today. Have a good day. Seung J. Lee From vadve at uiuc.edu Mon May 28 23:07:38 2007 From: vadve at uiuc.edu (Vikram S. Adve) Date: Mon, 28 May 2007 23:07:38 -0500 Subject: [LLVMdev] LLVM website down today? In-Reply-To: <20070528225514.AQI70590@expms2.cites.uiuc.edu> References: <20070528225514.AQI70590@expms2.cites.uiuc.edu> Message-ID: <102D467C-016A-49C9-962E-C10CE15C21A1@uiuc.edu> It works for me. --Vikram http://www.cs.uiuc.edu/~vadve http://llvm.cs.uiuc.edu/ On May 28, 2007, at 10:55 PM, Seung Jae Lee wrote: > Hello. > I just wonder if LLVM website is down today. > Have a good day. > > Seung J. Lee > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20070528/00a76569/attachment.html From sabre at nondot.org Tue May 29 11:10:10 2007 From: sabre at nondot.org (Chris Lattner) Date: Tue, 29 May 2007 09:10:10 -0700 (PDT) Subject: [LLVMdev] license file In-Reply-To: <84decce20705281617pb73b7f0r5d629ec607a8baf8@mail.gmail.com> References: <84decce20705281617pb73b7f0r5d629ec607a8baf8@mail.gmail.com> Message-ID: On Mon, 28 May 2007, Scott Graham wrote: > I noticed that http://llvm.org/releases/2.0/LICENSE.TXT pointed to by a > variety of places on llvm.org does not exist. Fixed, thanks! -Chris -- http://nondot.org/sabre/ http://llvm.org/ From manishagg22 at gmail.com Tue May 29 11:12:26 2007 From: manishagg22 at gmail.com (manishagg22 at gmail.com) Date: Tue, 29 May 2007 21:42:26 +0530 Subject: [LLVMdev] regarding LLVM Message-ID: <31ba424e0705290912v730bd949p2af62a7c0826cece@mail.gmail.com> Hi All, I have a question, Today i had read a mail regarding LLVM in gcc mailing list(http://gcc.gnu.org/ml/gcc/2005-12/msg00045.html) in which it is wriiten that it is difficult to present souce code information through LLVM bytecode as it is three-address code style, Is it really difficult? Thanks and Regards Manish From omiga at ustc.edu Tue May 29 11:18:41 2007 From: omiga at ustc.edu (omiga) Date: Wed, 30 May 2007 00:18:41 +0800 Subject: [LLVMdev] (no subject) Message-ID: <200705300018410571553@ustc.edu> Hi everyone, Llvm-gcc compiles the programs into bytecodes with some optimizations. How can I get unoptimized bytecodes? Thanks. Regards, -Ying -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20070530/5f793e95/attachment.html From lee225 at uiuc.edu Tue May 29 11:33:39 2007 From: lee225 at uiuc.edu (Seung Jae Lee) Date: Tue, 29 May 2007 11:33:39 -0500 (CDT) Subject: [LLVMdev] (no subject) Message-ID: <20070529113339.AQJ22862@expms2.cites.uiuc.edu> Hello. Please use llvm-gcc4 with -O[01234] options. You can see the example here: http://llvm.org/docs/GettingStarted.html#tutorial4 Seung J. Lee ---- Original message ---- >Date: Wed, 30 May 2007 00:18:41 +0800 >From: "omiga" >Subject: [LLVMdev] (no subject) >To: "llvmdev" > > Hi everyone, > > Llvm-gcc compiles the programs into bytecodes with > some optimizations. How can I get unoptimized > bytecodes? > Thanks. > > > Regards, > > -Ying >________________ >_______________________________________________ >LLVM Developers mailing list >LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev ------------------------------------------------ Phone: +1-217-377-1932 Webpage: http://struct.er.ro Graduate Research Assistant Dept. of Civil & Environmental Engineering University of Illinois at Urbana-Champaign ------------------------------------------------ From lee225 at uiuc.edu Tue May 29 11:35:03 2007 From: lee225 at uiuc.edu (Seung Jae Lee) Date: Tue, 29 May 2007 11:35:03 -0500 (CDT) Subject: [LLVMdev] (no subject) Message-ID: <20070529113503.AQJ22976@expms2.cites.uiuc.edu> If you use llvm-gcc3, you can make an unoptimized like this: llvm-gcc -S hello.c -o hello.s Seung J. Lee ---- Original message ---- >Date: Wed, 30 May 2007 00:18:41 +0800 >From: "omiga" >Subject: [LLVMdev] (no subject) >To: "llvmdev" > > Hi everyone, > > Llvm-gcc compiles the programs into bytecodes with > some optimizations. How can I get unoptimized > bytecodes? > Thanks. > > > Regards, > > -Ying >________________ >_______________________________________________ >LLVM Developers mailing list >LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From scott.llvm at h4ck3r.net Tue May 29 11:36:51 2007 From: scott.llvm at h4ck3r.net (Scott Graham) Date: Tue, 29 May 2007 09:36:51 -0700 Subject: [LLVMdev] (no subject) In-Reply-To: <200705300018410571553@ustc.edu> References: <200705300018410571553@ustc.edu> Message-ID: <84decce20705290936k6d2667eeg3ebc79ad7532c5dd@mail.gmail.com> Using llvm-gcc -emit-llvm -O0 -S blah.c will give you blah.s that is unoptimized. I guess passing that to llvm-as would get you an unoptimized .bc. llvm-as -debug-pass=Arguments blah.ll says it is only doing Pass Arguments: -domtree -etforest -verify scott On 5/29/07, omiga wrote: > > Hi everyone, > > Llvm-gcc compiles the programs into bytecodes with some optimizations. > How can I get unoptimized bytecodes? > Thanks. > > > Regards, > > -Ying > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20070529/94dc6318/attachment-0001.html From sabre at nondot.org Tue May 29 12:15:30 2007 From: sabre at nondot.org (Chris Lattner) Date: Tue, 29 May 2007 10:15:30 -0700 (PDT) Subject: [LLVMdev] Developer Meeting videos Message-ID: Hi Everyone, I set up a page to host the videos and slides from the meeting, and uploaded all the videos: http://llvm.org/devmtg/2007-05/index.html So far, I only have one set of slides on the page - please send me your slides! :) Also, I'd appreciate it if someone would write a blurb describing an overview of the meeting, etc at the top. Also, Scott, please let me know when it's ok to add your video to the page. Enjoy, -Chris -- http://nondot.org/sabre/ http://llvm.org/ From kenneth.hoste at elis.ugent.be Tue May 29 14:11:55 2007 From: kenneth.hoste at elis.ugent.be (Kenneth Hoste) Date: Tue, 29 May 2007 21:11:55 +0200 Subject: [LLVMdev] Developer Meeting videos In-Reply-To: References: Message-ID: <78ACB486-A0F5-4438-AC45-6F39A4BC6D22@elis.ugent.be> Hi Chris, On 29 May 2007, at 19:15, Chris Lattner wrote: > > Hi Everyone, > > I set up a page to host the videos and slides from the meeting, and > uploaded all the videos: > http://llvm.org/devmtg/2007-05/index.html Wow, thanks! That was quicker than I expected... I will be watching every one of these in the next couple of days. One minor detail: the last video (Feedback), so have number 15 instead of 14 (unless that is intentional). greetings, Kenneth > > So far, I only have one set of slides on the page - please send me > your > slides! :) Also, I'd appreciate it if someone would write a blurb > describing an overview of the meeting, etc at the top. > > Also, Scott, please let me know when it's ok to add your video to the > page. > > Enjoy, > > -Chris > > -- > http://nondot.org/sabre/ > http://llvm.org/ > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev -- Computer Science is no more about computers than astronomy is about telescopes. (E. W. Dijkstra) Kenneth Hoste ELIS - Ghent University email: kenneth.hoste at elis.ugent.be blog: http://www.elis.ugent.be/~kehoste/blog website: http://www.elis.ugent.be/~kehoste From sabre at nondot.org Tue May 29 15:54:42 2007 From: sabre at nondot.org (Chris Lattner) Date: Tue, 29 May 2007 13:54:42 -0700 (PDT) Subject: [LLVMdev] Developer Meeting videos In-Reply-To: <78ACB486-A0F5-4438-AC45-6F39A4BC6D22@elis.ugent.be> References: <78ACB486-A0F5-4438-AC45-6F39A4BC6D22@elis.ugent.be> Message-ID: On Tue, 29 May 2007, Kenneth Hoste wrote: > One minor detail: the last video (Feedback), so have number 15 > instead of 14 (unless that is intentional). Fixed, thanks, -chris >> >> So far, I only have one set of slides on the page - please send me >> your >> slides! :) Also, I'd appreciate it if someone would write a blurb >> describing an overview of the meeting, etc at the top. >> >> Also, Scott, please let me know when it's ok to add your video to the >> page. >> >> Enjoy, >> >> -Chris >> >> -- >> http://nondot.org/sabre/ >> http://llvm.org/ >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > -Chris -- http://nondot.org/sabre/ http://llvm.org/ From bram.adams at ugent.be Tue May 29 16:29:49 2007 From: bram.adams at ugent.be (Bram Adams) Date: Tue, 29 May 2007 23:29:49 +0200 Subject: [LLVMdev] Code generation issues Message-ID: <094F3B13-91FB-4FDD-A8EA-83958AA3D8E9@ugent.be> Hi, Today I managed to link ioquake3, but generating a binary does not work yet. 1) On OSX, I get: Error: Code generator does not support intrinsic function 'llvm.ppc.altivec.lvsl'! when I do: llc file.bc -march=c -o file.c 2) On Linux X86, llc does not give any problem, but I get this while compiling the generated .c file: error: unknown register name 'S' in 'asm' This is the offending line (notice the "S" on the last line): __asm__ volatile ("\tpushal\t\t\t\t\n\tmovl %0,%%esi\t\t\n\tmovl % 1,%%edi\t\t\n\tcall *%2\t\t\t\n\tmovl %%esi,%0\t\t\n\tmo\ vl %%edi,%1\t\t\n\tpopal\t\t\t\t\n" :"=m"(memProgramStack_2E_5872),"=m"(memOpStack_2E_5873) :"m"(memEntryPoint_2E_5874),"m"(memProgramStack_2E_5872),"m"(me mOpStack_2E_5873) :"D","S"); Apparently, leaving out "S" helps (compiling the .c file works), but what does it do and why is it here? 3) Regarding bug 1446 (http://llvm.org/bugs/show_bug.cgi?id=1446): the proposed patch for the file called sv_client.c indeed works on OSX, but on Linux X86 -O3 it still does not work. More in particular, the frontend is now stuck inside the for-loop on lines 176-->391 of PromoteMemoryToRegister.cpp when in the control flow of -scalarrepl: #4 0x08764f72 in (anonymous namespace)::PromoteMem2Reg::run (this=0xbff9bfa0) at /home/bram/workspace/svn/aspicere2/trunk/llvm/lib/Transforms/ Utils/PromoteMemoryToRegister.cpp:271 #5 0x08767021 in llvm::PromoteMemToReg (Allocas=@0xbff9c120, ET=@0x8b14c10, DF=@0x8b14d98, AST=0x0) at /home/bram/workspace/svn/aspicere2/trunk/llvm/lib/Transforms/ Utils/PromoteMemoryToRegister.cpp:812 #6 0x08744713 in (anonymous namespace)::SROA::performPromotion (this=0x8b14f38, F=@0x8bc8468) at /home/bram/workspace/svn/aspicere2/trunk/llvm/lib/Transforms/ Scalar/ScalarReplAggregates.cpp:130 #7 0x087445ba in (anonymous namespace)::SROA::runOnFunction (this=0x8b14f38, F=@0x8bc8468) at /home/bram/workspace/svn/aspicere2/trunk/llvm/lib/Transforms/ Scalar/ScalarReplAggregates.cpp:101 #8 0x08826499 in llvm::FPPassManager::runOnFunction (this=0x8b15d00, F=@0x8bc8468) at /home/bram/workspace/svn/aspicere2/trunk/llvm/lib/VMCore/ PassManager.cpp:1145 #9 0x08826237 in llvm::FunctionPassManagerImpl::run (this=0x8b14e78, F=@0x8bc8468) at /home/bram/workspace/svn/aspicere2/trunk/llvm/lib/VMCore/ PassManager.cpp:1103 #10 0x0882611f in llvm::FunctionPassManager::run (this=0x8b156e8, F=@0x8bc8468) at /home/bram/workspace/svn/aspicere2/trunk/llvm/lib/VMCore/ PassManager.cpp:1048 Kind regards, Bram Adams GH-SEL, INTEC, Ghent University (Belgium) From isanbard at gmail.com Tue May 29 17:06:55 2007 From: isanbard at gmail.com (Bill Wendling) Date: Tue, 29 May 2007 15:06:55 -0700 Subject: [LLVMdev] Code generation issues In-Reply-To: <094F3B13-91FB-4FDD-A8EA-83958AA3D8E9@ugent.be> References: <094F3B13-91FB-4FDD-A8EA-83958AA3D8E9@ugent.be> Message-ID: <16e5fdf90705291506pc111173hc0032578f141b3be@mail.gmail.com> Hi Bram, Could you submit bug reports for all of these problems? Thanks! -bw On 5/29/07, Bram Adams wrote: > Hi, > > Today I managed to link ioquake3, but generating a binary does not > work yet. > > > 1) On OSX, I get: > > Error: Code generator does not support intrinsic function > 'llvm.ppc.altivec.lvsl'! > > when I do: llc file.bc -march=c -o file.c > > > 2) On Linux X86, llc does not give any problem, but I get this while > compiling the generated .c file: > > error: unknown register name 'S' in 'asm' > > This is the offending line (notice the "S" on the last line): > > __asm__ volatile ("\tpushal\t\t\t\t\n\tmovl %0,%%esi\t\t\n\tmovl % > 1,%%edi\t\t\n\tcall *%2\t\t\t\n\tmovl %%esi,%0\t\t\n\tmo\ > vl %%edi,%1\t\t\n\tpopal\t\t\t\t\n" > :"=m"(memProgramStack_2E_5872),"=m"(memOpStack_2E_5873) > :"m"(memEntryPoint_2E_5874),"m"(memProgramStack_2E_5872),"m"(me > mOpStack_2E_5873) > :"D","S"); > > Apparently, leaving out "S" helps (compiling the .c file works), but > what does it do and why is it here? > > > 3) Regarding bug 1446 (http://llvm.org/bugs/show_bug.cgi?id=1446): > the proposed patch for the file called sv_client.c indeed works on > OSX, but on Linux X86 -O3 it still does not work. More in particular, > the frontend is now stuck inside the for-loop on lines 176-->391 of > PromoteMemoryToRegister.cpp when in the control flow of -scalarrepl: > > #4 0x08764f72 in (anonymous namespace)::PromoteMem2Reg::run > (this=0xbff9bfa0) > at /home/bram/workspace/svn/aspicere2/trunk/llvm/lib/Transforms/ > Utils/PromoteMemoryToRegister.cpp:271 > #5 0x08767021 in llvm::PromoteMemToReg (Allocas=@0xbff9c120, > ET=@0x8b14c10, DF=@0x8b14d98, AST=0x0) > at /home/bram/workspace/svn/aspicere2/trunk/llvm/lib/Transforms/ > Utils/PromoteMemoryToRegister.cpp:812 > #6 0x08744713 in (anonymous namespace)::SROA::performPromotion > (this=0x8b14f38, F=@0x8bc8468) > at /home/bram/workspace/svn/aspicere2/trunk/llvm/lib/Transforms/ > Scalar/ScalarReplAggregates.cpp:130 > #7 0x087445ba in (anonymous namespace)::SROA::runOnFunction > (this=0x8b14f38, F=@0x8bc8468) > at /home/bram/workspace/svn/aspicere2/trunk/llvm/lib/Transforms/ > Scalar/ScalarReplAggregates.cpp:101 > #8 0x08826499 in llvm::FPPassManager::runOnFunction (this=0x8b15d00, > F=@0x8bc8468) > at /home/bram/workspace/svn/aspicere2/trunk/llvm/lib/VMCore/ > PassManager.cpp:1145 > #9 0x08826237 in llvm::FunctionPassManagerImpl::run (this=0x8b14e78, > F=@0x8bc8468) > at /home/bram/workspace/svn/aspicere2/trunk/llvm/lib/VMCore/ > PassManager.cpp:1103 > #10 0x0882611f in llvm::FunctionPassManager::run (this=0x8b156e8, > F=@0x8bc8468) > at /home/bram/workspace/svn/aspicere2/trunk/llvm/lib/VMCore/ > PassManager.cpp:1048 > > > > Kind regards, > > > Bram Adams > GH-SEL, INTEC, Ghent University (Belgium) > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From madeonamac at gmail.com Tue May 29 18:44:37 2007 From: madeonamac at gmail.com (Gabriel McArthur) Date: Tue, 29 May 2007 18:44:37 -0500 Subject: [LLVMdev] Developer Meeting videos In-Reply-To: References: <78ACB486-A0F5-4438-AC45-6F39A4BC6D22@elis.ugent.be> Message-ID: <34D4D527-8A74-4FAC-997B-56F699FA775E@gmail.com> In terms of promoting LLVM, it might be nice to actually post those on a site like youTube, where it might get more exposure -- I think that they have a 'developer' or 'software' sub-genre (like the 'Google-talk' series). -Gabe On May 29, 2007, at 3:54 PM, Chris Lattner wrote: > On Tue, 29 May 2007, Kenneth Hoste wrote: >> One minor detail: the last video (Feedback), so have number 15 >> instead of 14 (unless that is intentional). > > Fixed, thanks, > > -chris > >>> >>> So far, I only have one set of slides on the page - please send me >>> your >>> slides! :) Also, I'd appreciate it if someone would write a blurb >>> describing an overview of the meeting, etc at the top. >>> >>> Also, Scott, please let me know when it's ok to add your video to >>> the >>> page. >>> >>> Enjoy, >>> >>> -Chris >>> >>> -- >>> http://nondot.org/sabre/ >>> http://llvm.org/ >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> > > -Chris > > -- > http://nondot.org/sabre/ > http://llvm.org/ > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From madeonamac at gmail.com Tue May 29 18:48:17 2007 From: madeonamac at gmail.com (Gabriel McArthur) Date: Tue, 29 May 2007 18:48:17 -0500 Subject: [LLVMdev] T-Shirts &| Supporting LLVM In-Reply-To: <16e5fdf90705291506pc111173hc0032578f141b3be@mail.gmail.com> References: <094F3B13-91FB-4FDD-A8EA-83958AA3D8E9@ugent.be> <16e5fdf90705291506pc111173hc0032578f141b3be@mail.gmail.com> Message-ID: <32AB709F-DAC6-4E95-9C26-81EA90A490F0@gmail.com> I was poking around, but I didn't spot a PayPal link for the t-shirts and/or supporting LLVM. Any follow-up from the pre-meeting discussions? -Gabe From sabre at nondot.org Tue May 29 23:31:15 2007 From: sabre at nondot.org (Chris Lattner) Date: Tue, 29 May 2007 21:31:15 -0700 (PDT) Subject: [LLVMdev] Code generation issues In-Reply-To: <094F3B13-91FB-4FDD-A8EA-83958AA3D8E9@ugent.be> References: <094F3B13-91FB-4FDD-A8EA-83958AA3D8E9@ugent.be> Message-ID: On Tue, 29 May 2007, Bram Adams wrote: > Today I managed to link ioquake3, but generating a binary does not > work yet. > 1) On OSX, I get: > > Error: Code generator does not support intrinsic function > 'llvm.ppc.altivec.lvsl'! > > when I do: llc file.bc -march=c -o file.c The C backend doesn't support all target-specific intrinsics. > 2) On Linux X86, llc does not give any problem, but I get this while > compiling the generated .c file: > > error: unknown register name 'S' in 'asm' > > This is the offending line (notice the "S" on the last line): > > __asm__ volatile ("\tpushal\t\t\t\t\n\tmovl %0,%%esi\t\t\n\tmovl % > 1,%%edi\t\t\n\tcall *%2\t\t\t\n\tmovl %%esi,%0\t\t\n\tmo\ > vl %%edi,%1\t\t\n\tpopal\t\t\t\t\n" > :"=m"(memProgramStack_2E_5872),"=m"(memOpStack_2E_5873) > :"m"(memEntryPoint_2E_5874),"m"(memProgramStack_2E_5872),"m"(me > mOpStack_2E_5873) > :"D","S"); > > Apparently, leaving out "S" helps (compiling the .c file works), but > what does it do and why is it here? Please file a bug with this in a self-contained .c file. Thanks! > 3) Regarding bug 1446 (http://llvm.org/bugs/show_bug.cgi?id=1446): > the proposed patch for the file called sv_client.c indeed works on > OSX, but on Linux X86 -O3 it still does not work. More in particular, > the frontend is now stuck inside the for-loop on lines 176-->391 of > PromoteMemoryToRegister.cpp when in the control flow of -scalarrepl: Very strange. Is everything up to date? -Chris -- http://nondot.org/sabre/ http://llvm.org/ From sabre at nondot.org Tue May 29 23:31:42 2007 From: sabre at nondot.org (Chris Lattner) Date: Tue, 29 May 2007 21:31:42 -0700 (PDT) Subject: [LLVMdev] Developer Meeting videos In-Reply-To: <34D4D527-8A74-4FAC-997B-56F699FA775E@gmail.com> References: <78ACB486-A0F5-4438-AC45-6F39A4BC6D22@elis.ugent.be> <34D4D527-8A74-4FAC-997B-56F699FA775E@gmail.com> Message-ID: On Tue, 29 May 2007, Gabriel McArthur wrote: > In terms of promoting LLVM, it might be nice to actually post those > on a site like youTube, where it might get more exposure -- I think > that they have a 'developer' or 'software' sub-genre (like the > 'Google-talk' series). Sure, go for it! -Chris > On May 29, 2007, at 3:54 PM, Chris Lattner wrote: > >> On Tue, 29 May 2007, Kenneth Hoste wrote: >>> One minor detail: the last video (Feedback), so have number 15 >>> instead of 14 (unless that is intentional). >> >> Fixed, thanks, >> >> -chris >> >>>> >>>> So far, I only have one set of slides on the page - please send me >>>> your >>>> slides! :) Also, I'd appreciate it if someone would write a blurb >>>> describing an overview of the meeting, etc at the top. >>>> >>>> Also, Scott, please let me know when it's ok to add your video to >>>> the >>>> page. >>>> >>>> Enjoy, >>>> >>>> -Chris >>>> >>>> -- >>>> http://nondot.org/sabre/ >>>> http://llvm.org/ >>>> _______________________________________________ >>>> LLVM Developers mailing list >>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>> >>> >> >> -Chris >> >> -- >> http://nondot.org/sabre/ >> http://llvm.org/ >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > -Chris -- http://nondot.org/sabre/ http://llvm.org/ From omiga at ustc.edu Wed May 30 00:42:35 2007 From: omiga at ustc.edu (omiga) Date: Wed, 30 May 2007 13:42:35 +0800 Subject: [LLVMdev] (no subject) References: <200705300018410571553@ustc.edu>, <84decce20705290936k6d2667eeg3ebc79ad7532c5dd@mail.gmail.com> Message-ID: <200705301342348202279@ustc.edu> It's worked. Thanks for your replies, Lee and Scott. -Ying -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20070530/fb5716ff/attachment.html From ebner at complang.tuwien.ac.at Wed May 30 09:47:17 2007 From: ebner at complang.tuwien.ac.at (Dietmar Ebner) Date: Wed, 30 May 2007 16:47:17 +0200 Subject: [LLVMdev] wrong codegen Message-ID: <1180536437.615.30.camel@cdbook2.complang.tuwien.ac.at> hi, the current release_20 branch seems to miscompile the following reduced testcase (not target architecture specific): #define UInt16 unsigned short #define UInt8 unsigned char UInt8 foo(UInt16 a) { return (UInt8)(((a >> 10) & 1) << 1); } it - misleadingly - optimizes the expression to something like (undef & 2). I guess the problem is related to the DAG combiner but I haven't done a thorough analysis yet. a quick search didn't bring up existing bug reports. is this a known problem? anybody else seeing this? - dietmar From asl at math.spbu.ru Wed May 30 11:14:39 2007 From: asl at math.spbu.ru (Anton Korobeynikov) Date: Wed, 30 May 2007 20:14:39 +0400 Subject: [LLVMdev] wrong codegen In-Reply-To: <1180536437.615.30.camel.SS716SS@cdbook2.complang.tuwien.ac.at> References: <1180536437.615.30.camel.SS716SS@cdbook2.complang.tuwien.ac.at> Message-ID: <1180541679.30952.25.camel@asl.dorms.spbu.ru> Hello, Dietmar > a quick search didn't bring up existing bug reports. is this a known > problem? anybody else seeing this? I cannot reproduce it here. Are you sure, that code is wrong? -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University. From sabre at nondot.org Wed May 30 11:31:00 2007 From: sabre at nondot.org (Chris Lattner) Date: Wed, 30 May 2007 09:31:00 -0700 (PDT) Subject: [LLVMdev] wrong codegen In-Reply-To: <1180536437.615.30.camel@cdbook2.complang.tuwien.ac.at> References: <1180536437.615.30.camel@cdbook2.complang.tuwien.ac.at> Message-ID: On Wed, 30 May 2007, Dietmar Ebner wrote: > the current release_20 branch seems to miscompile the following reduced > testcase (not target architecture specific): > > #define UInt16 unsigned short > #define UInt8 unsigned char > UInt8 foo(UInt16 a) { > return (UInt8)(((a >> 10) & 1) << 1); > } > > it - misleadingly - optimizes the expression to something like (undef & > 2). I guess the problem is related to the DAG combiner but I haven't > done a thorough analysis yet. > > a quick search didn't bring up existing bug reports. is this a known > problem? anybody else seeing this? Verified, I filed this bug, I'm investigating. Thanks! http://llvm.org/bugs/show_bug.cgi?id=1473 -Chris -- http://nondot.org/sabre/ http://llvm.org/ From gordonhenriksen at mac.com Wed May 30 12:41:29 2007 From: gordonhenriksen at mac.com (Gordon Henriksen) Date: Wed, 30 May 2007 13:41:29 -0400 Subject: [LLVMdev] Developer Meeting videos In-Reply-To: References: <78ACB486-A0F5-4438-AC45-6F39A4BC6D22@elis.ugent.be> <34D4D527-8A74-4FAC-997B-56F699FA775E@gmail.com> Message-ID: <2ADBDB84-C440-4FFB-92BD-5DBDA43EE0C9@mac.com> http://www.youtube.com/view_play_list?p=AA11ACE45D6B0E4C ? Gordon From sabre at nondot.org Wed May 30 13:06:49 2007 From: sabre at nondot.org (Chris Lattner) Date: Wed, 30 May 2007 11:06:49 -0700 (PDT) Subject: [LLVMdev] Developer Meeting videos In-Reply-To: <2ADBDB84-C440-4FFB-92BD-5DBDA43EE0C9@mac.com> References: <78ACB486-A0F5-4438-AC45-6F39A4BC6D22@elis.ugent.be> <34D4D527-8A74-4FAC-997B-56F699FA775E@gmail.com> <2ADBDB84-C440-4FFB-92BD-5DBDA43EE0C9@mac.com> Message-ID: On Wed, 30 May 2007, Gordon Henriksen wrote: > http://www.youtube.com/view_play_list?p=AA11ACE45D6B0E4C Very cool. Is that a stable URL? If so, I'll add it to the dev mtg page. Thanks, -Chris -- http://nondot.org/sabre/ http://llvm.org/ From gordonhenriksen at mac.com Wed May 30 13:03:56 2007 From: gordonhenriksen at mac.com (Gordon Henriksen) Date: Wed, 30 May 2007 14:03:56 -0400 Subject: [LLVMdev] Developer Meeting videos In-Reply-To: References: <78ACB486-A0F5-4438-AC45-6F39A4BC6D22@elis.ugent.be> <34D4D527-8A74-4FAC-997B-56F699FA775E@gmail.com> <2ADBDB84-C440-4FFB-92BD-5DBDA43EE0C9@mac.com> Message-ID: <5503359A-2097-4595-AEC5-7131DF266F14@mac.com> On May 30, 2007, at 14:06, Chris Lattner wrote: > On Wed, 30 May 2007, Gordon Henriksen wrote: > >> http://www.youtube.com/view_play_list?p=AA11ACE45D6B0E4C > > Very cool. Is that a stable URL? If so, I'll add it to the dev > mtg page. It is indeed. ? Gordon From simpsom at umd.edu Wed May 30 16:33:40 2007 From: simpsom at umd.edu (Matthew Simpson) Date: Wed, 30 May 2007 17:33:40 -0400 Subject: [LLVMdev] llvm-test and FORTRAN Message-ID: <9b41a0070705301433y30f12c92r5587f7162e979c@mail.gmail.com> Hi everyone, Is there a trick to getting the FORTRAN benchmarks of spec2006 to compile using the nightly tester? The configure script correctly located my f2c installation yet the benchmarks do not compile. Thanks for any help. -- Matthew Simpson From bram.adams at ugent.be Wed May 30 16:54:23 2007 From: bram.adams at ugent.be (Bram Adams) Date: Wed, 30 May 2007 23:54:23 +0200 Subject: [LLVMdev] Code generation issues In-Reply-To: References: <094F3B13-91FB-4FDD-A8EA-83958AA3D8E9@ugent.be> Message-ID: Hi, Op 30-mei-07, om 06:31 heeft Chris Lattner het volgende geschreven: >> when I do: llc file.bc -march=c -o file.c > > The C backend doesn't support all target-specific intrinsics. OK (http://llvm.org/bugs/show_bug.cgi?id=1481). > Please file a bug with this in a self-contained .c file. Thanks! Has happened: http://llvm.org/bugs/show_bug.cgi?id=1482. > Very strange. Is everything up to date? Yes, I applied your patch but it still hangs on -O3, not on -O0 (http://llvm.org/bugs/show_bug.cgi?id=1446). Kind regards, Bram Adams GH-SEL, INTEC, Ghent University (Belgium) From sabre at nondot.org Wed May 30 17:57:08 2007 From: sabre at nondot.org (Chris Lattner) Date: Wed, 30 May 2007 15:57:08 -0700 (PDT) Subject: [LLVMdev] Code generation issues In-Reply-To: References: <094F3B13-91FB-4FDD-A8EA-83958AA3D8E9@ugent.be> Message-ID: On Wed, 30 May 2007, Bram Adams wrote: > Yes, I applied your patch but it still hangs on -O3, not on -O0 > (http://llvm.org/bugs/show_bug.cgi?id=1446). Did you recompile llvm-gcc after updating llvm? -Chris -- http://nondot.org/sabre/ http://llvm.org/ From sabre at nondot.org Wed May 30 20:19:36 2007 From: sabre at nondot.org (Chris Lattner) Date: Wed, 30 May 2007 18:19:36 -0700 (PDT) Subject: [LLVMdev] llvm-test and FORTRAN In-Reply-To: <9b41a0070705301433y30f12c92r5587f7162e979c@mail.gmail.com> References: <9b41a0070705301433y30f12c92r5587f7162e979c@mail.gmail.com> Message-ID: On Wed, 30 May 2007, Matthew Simpson wrote: > Is there a trick to getting the FORTRAN benchmarks of spec2006 to > compile using the nightly tester? The configure script correctly > located my f2c installation yet the benchmarks do not compile. f2c doesn't support many of the spec 2k6 programs (e.g. that use fortran 95 features). We've had more luck with the NAG fortran -> C converter. -Chris -- http://nondot.org/sabre/ http://llvm.org/ From madeonamac at gmail.com Wed May 30 23:41:57 2007 From: madeonamac at gmail.com (Gabriel McArthur) Date: Wed, 30 May 2007 23:41:57 -0500 Subject: [LLVMdev] Renaming Message-ID: <76F6C868-9284-44BF-85D1-CA72E2DEFAB8@gmail.com> Without wishing to fan the flames, this struck me as interesting. -Gabe Qubit% diff -u Name.html.orig Name.html --- Name.html.orig 2007-05-30 23:22:11.000000000 -0500 +++ Name.html 2007-05-30 23:29:56.000000000 -0500 @@ -365,7 +365,7 @@ the weapons of the Gods LemnosGreek mythology: the island of Hephaestus workshop - Gabe McArthurWyrmAlong the same 'dragon' line, + Gabe McArthurWyrmAlong the same 'dragon' line, here's a little old english for you. Also it seems www.wyrm.org is for sale. 
        "                     Dracan ec scufun,
@@ -378,6 +378,8 @@
          Beowulf
+ Puck"Portable Universal(?) Compiler Kit" or "Puck's a Universal Compiler Kit". Short on the command line. + Long on ambition, allusions of speed, and a bit of impish delight about the edges. Christopher LambTakoaFinnish for 'to hammer' or 'forge'. takoa.org is unclaimed. The image of a hammer is pretty iconographic. Ralph Corderoy From sabre at nondot.org Thu May 31 01:25:21 2007 From: sabre at nondot.org (Chris Lattner) Date: Wed, 30 May 2007 23:25:21 -0700 (PDT) Subject: [LLVMdev] Problem in llvm gcc back-end In-Reply-To: References: Message-ID: On Mon, 28 May 2007, quho wrote: > While I testing some code, I found some problem on Union handling. > I've wrte following test code, and it has union assignment. BTW, this is fixed in mainline now. Thanks for the report. -Chris > The code's output is > > from pointerToUnion: chars mystring, length 64 > from original: chars mystring, length 8000 > > It's caused by second char member(charlength) of LongestMember. > > For union assignment, llvm-backend seems generates assigning each > member of largest union member. (I've checked it on llvm assembly > level..) > But sometimes there is padding between members and it's different for members. > > So in my opinion you should handle union assignment as pseudo array of > word(or byte). > (it's same for argument passing..) > > > ===================================================== > #include > > struct MyString { > char *chars; > int length; > }; > > struct LongestMember { > char *chars; > char charlength; > int empty1; > int empty2; > }; > > typedef union { > MyString string; > LongestMember mt; > } UnionType; > > > int main() { > UnionType original; > UnionType *pointerToUnion; > UnionType buffer; > > pointerToUnion = &buffer; > > original.string.chars = "mystring"; > original.string.length = 8000; > > *pointerToUnion = original; > > printf("from pointerToUnion: chars %s, length %d\n", > pointerToUnion->string.chars, pointerToUnion->string.length); > printf("from original: chars %s, length %d\n", > original.string.chars, original.string.length); > } > ===================================================== > > > Thanks, > Quho. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > -Chris -- http://nondot.org/sabre/ http://llvm.org/ From ebner at complang.tuwien.ac.at Thu May 31 02:45:34 2007 From: ebner at complang.tuwien.ac.at (Dietmar Ebner) Date: Thu, 31 May 2007 09:45:34 +0200 Subject: [LLVMdev] wrong codegen In-Reply-To: References: <1180536437.615.30.camel@cdbook2.complang.tuwien.ac.at> Message-ID: <1180597534.2593.2.camel@cdbook2.complang.tuwien.ac.at> hi, On Wed, 2007-05-30 at 09:31 -0700, Chris Lattner wrote: > On Wed, 30 May 2007, Dietmar Ebner wrote: > > the current release_20 branch seems to miscompile the following > reduced > > testcase (not target architecture specific): > > > > #define UInt16 unsigned short > > #define UInt8 unsigned char > > UInt8 foo(UInt16 a) { > > return (UInt8)(((a >> 10) & 1) << 1); > > } > Verified, I filed this bug, I'm investigating. Thanks! > > http://llvm.org/bugs/show_bug.cgi?id=1473 thanks a lot for the quick fix! it solves the problem for me. - dietmar From bram.adams at ugent.be Thu May 31 05:31:46 2007 From: bram.adams at ugent.be (Bram Adams) Date: Thu, 31 May 2007 12:31:46 +0200 Subject: [LLVMdev] Code generation issues In-Reply-To: References: <094F3B13-91FB-4FDD-A8EA-83958AA3D8E9@ugent.be> Message-ID: <61A0A295-6CDF-42C4-BEB5-B3EB5F21BE80@ugent.be> Hi, Op 31-mei-07, om 00:57 heeft Chris Lattner het volgende geschreven: > Did you recompile llvm-gcc after updating llvm? That did the trick. I didn't know that the LLVM optimisations were statically linked into the frontend (so that's why LLVM itself is needed during the build of the frontend). Sorry for the trouble, Bram Adams GH-SEL, INTEC, Ghent University (Belgium) From chuck.c.zhao at intel.com Thu May 31 11:13:05 2007 From: chuck.c.zhao at intel.com (Zhao, Chuck C) Date: Thu, 31 May 2007 09:13:05 -0700 Subject: [LLVMdev] are the Developer Meeting slides available? Message-ID: <8A2A25DA975FE34F8DF544EB0E9CE316015DEB12@scsmsx414.amr.corp.intel.com> I was working at the time, so I can't attend. However, I am very interested in the talk. If the presentation slides are available, could you please post me a link? Thank you Chuck Zhao Intel Research -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20070531/c9b56c7e/attachment.html From sabre at nondot.org Thu May 31 11:49:36 2007 From: sabre at nondot.org (Chris Lattner) Date: Thu, 31 May 2007 09:49:36 -0700 (PDT) Subject: [LLVMdev] are the Developer Meeting slides available? In-Reply-To: <8A2A25DA975FE34F8DF544EB0E9CE316015DEB12@scsmsx414.amr.corp.intel.com> References: <8A2A25DA975FE34F8DF544EB0E9CE316015DEB12@scsmsx414.amr.corp.intel.com> Message-ID: On Thu, 31 May 2007, Zhao, Chuck C wrote: > I was working at the time, so I can't attend. > However, I am very interested in the talk. > If the presentation slides are available, could you please post me a > link? Yep, slides and video are available here: http://llvm.org/devmtg/2007-05/ We're still missing some people's slides though (hint hint John and Reid :), -Chris -- http://nondot.org/sabre/ http://llvm.org/ From criswell at cs.uiuc.edu Thu May 31 11:40:46 2007 From: criswell at cs.uiuc.edu (John T. Criswell) Date: Thu, 31 May 2007 11:40:46 -0500 Subject: [LLVMdev] are the Developer Meeting slides available? In-Reply-To: References: <8A2A25DA975FE34F8DF544EB0E9CE316015DEB12@scsmsx414.amr.corp.intel.com> Message-ID: <465EFA8E.1080206@cs.uiuc.edu> Chris Lattner wrote: > On Thu, 31 May 2007, Zhao, Chuck C wrote: > >> I was working at the time, so I can't attend. >> However, I am very interested in the talk. >> If the presentation slides are available, could you please post me a >> link? >> > > Yep, slides and video are available here: > http://llvm.org/devmtg/2007-05/ > > We're still missing some people's slides though (hint hint John and Reid > :), > :) So, my excuse for not submitting my slides yet is that I'm on vacation this week. I might be able to get them in today or tomorrow morning, but if not, I'll get them in next Tuesday (when I return to the office). -- John T. > -Chris > > From sabre at nondot.org Thu May 31 12:05:37 2007 From: sabre at nondot.org (Chris Lattner) Date: Thu, 31 May 2007 10:05:37 -0700 (PDT) Subject: [LLVMdev] are the Developer Meeting slides available? In-Reply-To: <465EFA8E.1080206@cs.uiuc.edu> References: <8A2A25DA975FE34F8DF544EB0E9CE316015DEB12@scsmsx414.amr.corp.intel.com> <465EFA8E.1080206@cs.uiuc.edu> Message-ID: On Thu, 31 May 2007, John T. Criswell wrote: > :) > So, my excuse for not submitting my slides yet is that I'm on vacation > this week. I might be able to get them in today or tomorrow morning, > but if not, I'll get them in next Tuesday (when I return to the office). Ahh, that's an acceptable excuse :). No hurry, any time that is convenient would be great, -Chris -- http://nondot.org/sabre/ http://llvm.org/ From cfr at adobe.com Thu May 31 15:54:17 2007 From: cfr at adobe.com (Chuck Rose III) Date: Thu, 31 May 2007 13:54:17 -0700 Subject: [LLVMdev] Advice on a VStudio specific patch Message-ID: <680422C0AA225644931C2F6DD07200DDB04F12@namail5.corp.adobe.com> Hola LLVMers, Our project is cross platform and on Windows we use VStudio 2005. VStudio presents a couple of issues related around it's STL implementation and also it's non-respect for the no-return semantic of abort(). I've fixed it locally, but I'd like to send a patch so I don't have to do this every time I update from the source repository. So.... if I'm fixing something for a specific compiler, do you think I should just do so for all compilers or should I put the differences in a #ifdef check for VStudio? Thanks, Chuck. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20070531/ee6e7e99/attachment.html From sabre at nondot.org Thu May 31 17:59:52 2007 From: sabre at nondot.org (Chris Lattner) Date: Thu, 31 May 2007 15:59:52 -0700 (PDT) Subject: [LLVMdev] Advice on a VStudio specific patch In-Reply-To: <680422C0AA225644931C2F6DD07200DDB04F12@namail5.corp.adobe.com> References: <680422C0AA225644931C2F6DD07200DDB04F12@namail5.corp.adobe.com> Message-ID: On Thu, 31 May 2007, Chuck Rose III wrote: > Our project is cross platform and on Windows we use VStudio 2005. > VStudio presents a couple of issues related around it's STL > implementation and also it's non-respect for the no-return semantic of > abort(). Ok. We want the source to be portable, so it's goodness to get these fixes into the main tree. > I've fixed it locally, but I'd like to send a patch so I don't have to > do this every time I update from the source repository. So.... if I'm > fixing something for a specific compiler, do you think I should just do > so for all compilers or should I put the differences in a #ifdef check > for VStudio? Can you send one example of what you're thinking of? We prefer to keep the main code #ifdef free, moving compiler-specific code to include/llvm/Support/Compiler.h. Depending on what you mean, this may or may not make sense though :) -Chris -- http://nondot.org/sabre/ http://llvm.org/ From cfr at adobe.com Thu May 31 18:15:56 2007 From: cfr at adobe.com (Chuck Rose III) Date: Thu, 31 May 2007 16:15:56 -0700 Subject: [LLVMdev] Advice on a VStudio specific patch In-Reply-To: References: <680422C0AA225644931C2F6DD07200DDB04F12@namail5.corp.adobe.com> Message-ID: <680422C0AA225644931C2F6DD07200DDB0509C@namail5.corp.adobe.com> Here are the two problem areas: RegisterInfoEmitter.cpp // Emit the subregister + index mapping function based on the information // calculated above. OS << "unsigned " << ClassName << "::getSubReg(unsigned RegNo, unsigned Index) const {\n" << " switch (RegNo) {\n" << " default: abort(); break;\n"; ... OS << " };\n"; OS << " return 0; // Visual Studio 2005 does not respect the no-return semantics of abort\n"; OS << "}\n\n"; Need this because otherwise the emitted function will fail to compile in VStudio. PredicateSimplifier.cpp: The other problem is subtle. In the Edge class (for example) this function will fail to compile in debug. iterator find(unsigned n, ETNode *Subtree) { iterator E = end(); for (iterator I = std::lower_bound(begin(), E, n); I != E && I->To == n; ++I) { if (Subtree->DominatedBy(I->Subtree)) return I; } return E; } The debug paths through VStudio's STL through the std::lower_bound function get to this template: template inline bool __CLRCALL_OR_CDECL _Debug_lt(const _Ty1& _Left, const _Ty2& _Right, const wchar_t *_Where, unsigned int _Line) { // test if _Left < _Right and operator< is strict weak ordering if (!(_Left < _Right)) return (false); else if (_Right < _Left) _DEBUG_ERROR2("invalid operator<", _Where, _Line); return (true); } The critical feature is that the A(unsigned to) const { return To > to; } friend bool operator<(unsigned to, const Edge& edge) { return edge.operator>(to); } There is a similar set of additions for ScopedRange. Adding the alternate comparitors and the return won't make things less portable, but it does crudify the code somewhat in order to get around the limitations of the compiler. Having a bunch of #ifdefs for VStudio probably is crudier still, however. :-) What do you think? Thanks, Chuck. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Chris Lattner Sent: Thursday, May 31, 2007 4:00 PM To: LLVM Developers Mailing List Subject: Re: [LLVMdev] Advice on a VStudio specific patch On Thu, 31 May 2007, Chuck Rose III wrote: > Our project is cross platform and on Windows we use VStudio 2005. > VStudio presents a couple of issues related around it's STL > implementation and also it's non-respect for the no-return semantic of > abort(). Ok. We want the source to be portable, so it's goodness to get these fixes into the main tree. > I've fixed it locally, but I'd like to send a patch so I don't have to > do this every time I update from the source repository. So.... if I'm > fixing something for a specific compiler, do you think I should just do > so for all compilers or should I put the differences in a #ifdef check > for VStudio? Can you send one example of what you're thinking of? We prefer to keep the main code #ifdef free, moving compiler-specific code to include/llvm/Support/Compiler.h. Depending on what you mean, this may or may not make sense though :) -Chris -- http://nondot.org/sabre/ http://llvm.org/ _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From sabre at nondot.org Thu May 31 19:21:00 2007 From: sabre at nondot.org (Chris Lattner) Date: Thu, 31 May 2007 17:21:00 -0700 (PDT) Subject: [LLVMdev] Advice on a VStudio specific patch In-Reply-To: <680422C0AA225644931C2F6DD07200DDB0509C@namail5.corp.adobe.com> References: <680422C0AA225644931C2F6DD07200DDB04F12@namail5.corp.adobe.com> <680422C0AA225644931C2F6DD07200DDB0509C@namail5.corp.adobe.com> Message-ID: On Thu, 31 May 2007, Chuck Rose III wrote: > Here are the two problem areas: > RegisterInfoEmitter.cpp > // Emit the subregister + index mapping function based on the > information > // calculated above. > OS << "unsigned " << ClassName > << "::getSubReg(unsigned RegNo, unsigned Index) const {\n" > << " switch (RegNo) {\n" > << " default: abort(); break;\n"; > ... > OS << " };\n"; > OS << " return 0; // Visual Studio 2005 does not respect the > no-return semantics of abort\n"; > OS << "}\n\n"; > > Need this because otherwise the emitted function will fail to compile in > VStudio. Ok. For this, I suggest just removing the break after the abort. visual studio will just think it falls through into the next case, which is harmless. > operator also ends up doing B isn't wonky. And since the B PredicateSimplifier.cpp, I needed to add some stuff like this: > > // these two together get me the unsigned < Edge operation > bool operator>(unsigned to) const { > return To > to; > } > There is a similar set of additions for ScopedRange. Okay, those sound easy and simple to add unconditionally. > Adding the alternate comparitors and the return won't make things less > portable, but it does crudify the code somewhat in order to get around > the limitations of the compiler. Having a bunch of #ifdefs for VStudio > probably is crudier still, however. :-) Right, sounds good. Please add them unconditionally, so no #ifdef's required :) -Chris > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Chris Lattner > Sent: Thursday, May 31, 2007 4:00 PM > To: LLVM Developers Mailing List > Subject: Re: [LLVMdev] Advice on a VStudio specific patch > > On Thu, 31 May 2007, Chuck Rose III wrote: >> Our project is cross platform and on Windows we use VStudio 2005. >> VStudio presents a couple of issues related around it's STL >> implementation and also it's non-respect for the no-return semantic of >> abort(). > > Ok. We want the source to be portable, so it's goodness to get these > fixes into the main tree. > >> I've fixed it locally, but I'd like to send a patch so I don't have to >> do this every time I update from the source repository. So.... if I'm >> fixing something for a specific compiler, do you think I should just > do >> so for all compilers or should I put the differences in a #ifdef check >> for VStudio? > > Can you send one example of what you're thinking of? We prefer to keep > the main code #ifdef free, moving compiler-specific code to > include/llvm/Support/Compiler.h. Depending on what you mean, this may > or > may not make sense though :) > > -Chris > > -Chris -- http://nondot.org/sabre/ http://llvm.org/ From rspencer at reidspencer.com Thu May 31 19:38:39 2007 From: rspencer at reidspencer.com (Reid Spencer) Date: Thu, 31 May 2007 17:38:39 -0700 Subject: [LLVMdev] T-Shirts & Supporting LLVM In-Reply-To: <32AB709F-DAC6-4E95-9C26-81EA90A490F0@gmail.com> References: <094F3B13-91FB-4FDD-A8EA-83958AA3D8E9@ugent.be> <16e5fdf90705291506pc111173hc0032578f141b3be@mail.gmail.com> <32AB709F-DAC6-4E95-9C26-81EA90A490F0@gmail.com> Message-ID: <1180658319.3076.51.camel@bashful.x10sys.com> All, Anyone who wishes to donate to the project can follow the directions for sending a check here: http://llvm.org/Funding.html If you can only pay by PayPal or credit card, PLEASE write to Vikram Adve (vadve at uiuc.edu) and ask him to update that page with the alternate payment details. FYI: while the T-Shirts provided at the meeting were "free", they were offered in the hope that there would be donations made in kind. The T-Shirts cost about $20.00US. If you feel like making a donation to the project, please use the directions on the Funding page. Please do NOT send any money to me! :) Reid. On Tue, 2007-05-29 at 18:48 -0500, Gabriel McArthur wrote: > I was poking around, but I didn't spot a PayPal link for the t-shirts > and/or supporting LLVM. Any follow-up from the pre-meeting > discussions? > -Gabe > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From me22.ca at gmail.com Thu May 31 21:11:50 2007 From: me22.ca at gmail.com (me22) Date: Thu, 31 May 2007 22:11:50 -0400 Subject: [LLVMdev] Advice on a VStudio specific patch In-Reply-To: <680422C0AA225644931C2F6DD07200DDB0509C@namail5.corp.adobe.com> References: <680422C0AA225644931C2F6DD07200DDB04F12@namail5.corp.adobe.com> <680422C0AA225644931C2F6DD07200DDB0509C@namail5.corp.adobe.com> Message-ID: On 31/05/07, Chuck Rose III wrote: > Here are the two problem areas: > > RegisterInfoEmitter.cpp > > // Emit the subregister + index mapping function based on the > information > // calculated above. > OS << "unsigned " << ClassName > << "::getSubReg(unsigned RegNo, unsigned Index) const {\n" > << " switch (RegNo) {\n" > << " default: abort(); break;\n"; > ... > OS << " };\n"; > OS << " return 0; // Visual Studio 2005 does not respect the > no-return semantics of abort\n"; > OS << "}\n\n"; > > Need this because otherwise the emitted function will fail to compile in > VStudio. > This might be more subtle than it seems. I'm assuming that since that actually fails, you have warnings-as-errors on. In compilers with good flow analysis that do have noreturn abort, the extra return should trigger an "unreachable code" warning, which will also prevent compilation with treat warnings as errors on... I know boost has a BOOST_UNREACHABLE_RETURN(x) macro for that situation; Perhaps LLVM should have something similar? ~ Scott McMurray From cfr at adobe.com Thu May 31 23:20:20 2007 From: cfr at adobe.com (Chuck Rose III) Date: Thu, 31 May 2007 21:20:20 -0700 Subject: [LLVMdev] Advice on a VStudio specific patch References: <680422C0AA225644931C2F6DD07200DDB04F12@namail5.corp.adobe.com><680422C0AA225644931C2F6DD07200DDB0509C@namail5.corp.adobe.com> Message-ID: <680422C0AA225644931C2F6DD07200DD3FFB8A@namail5.corp.adobe.com> Nope, it generates an error, not a warning-as-error. (LLVM generates a whole host of warnings when run through the VStudio STL implementation). I misspoke earlier about VStudio ignoring noreturn. I investigated further and found that the implementation of abort in VStudio 2k5 is not tagged noreturn, hence the error. Thanks, Chuck. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu on behalf of me22 Sent: Thu 5/31/2007 7:11 PM To: LLVM Developers Mailing List Subject: Re: [LLVMdev] Advice on a VStudio specific patch On 31/05/07, Chuck Rose III wrote: > Here are the two problem areas: > > RegisterInfoEmitter.cpp > > // Emit the subregister + index mapping function based on the > information > // calculated above. > OS << "unsigned " << ClassName > << "::getSubReg(unsigned RegNo, unsigned Index) const {\n" > << " switch (RegNo) {\n" > << " default: abort(); break;\n"; > ... > OS << " };\n"; > OS << " return 0; // Visual Studio 2005 does not respect the > no-return semantics of abort\n"; > OS << "}\n\n"; > > Need this because otherwise the emitted function will fail to compile in > VStudio. > This might be more subtle than it seems. I'm assuming that since that actually fails, you have warnings-as-errors on. In compilers with good flow analysis that do have noreturn abort, the extra return should trigger an "unreachable code" warning, which will also prevent compilation with treat warnings as errors on... I know boost has a BOOST_UNREACHABLE_RETURN(x) macro for that situation; Perhaps LLVM should have something similar? ~ Scott McMurray _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev