split lui_movf pattern on mips?

2010-04-29 Thread Amker.Cheng
HI: There is comment on lui_movf in mips.md like following, ;; because we don't split it. FIXME: we should split instead. I can split it into a move and a condmove(movesi_on_cc) insns , like (define_split [(set (match_operand:CC 0 "d_operand" "") (match_operand:CC 1 "fcc_reload_opera

Re: GIMPLE Front End (GSOC 2010)

2010-04-29 Thread Sandeep Soni
On Thu, Apr 29, 2010 at 11:01 PM, Manuel López-Ibáñez wrote: > On 29 April 2010 19:25, Sandeep Soni wrote: >> I added the following page to the wiki. >> >> http://gcc.gnu.org/wiki/GimpleFrontEnd >> >> Any comments/suggestions or ideas related to the project are welcome. > > Hi Sandy, > > It may b

Parallelized loads and widening mults cont:ed (was: Re: GCC porting tutorials)

2010-04-29 Thread Hans-Peter Nilsson
> Date: Thu, 29 Apr 2010 08:55:56 +0200 (CEST) > From: "Jonas Paulsson" > It feels good to know that the widening mults issue has been > resolved Yes, nice, and as late as last week too, though the patch was from February. > as > it was a bit of a disapointment I noted the erratic behaviour wit

Re: GCC-4.5.0 comparison with previous releases and LLVM-2.7 on SPEC2000 for x86/x86_64

2010-04-29 Thread Xinliang David Li
On Thu, Apr 29, 2010 at 4:03 PM, Jan Hubicka wrote: >> 2010/4/30 Jan Hubicka : >> >> Thanks for the suggestion. Raksit currently is busy with merging trunk >> >> changes back to lw-ipo branch which can be a daunting task. After that >> >> this can be done.  (Our internal release is based on 4.4).

Re: GCC-4.5.0 comparison with previous releases and LLVM-2.7 on SPEC2000 for x86/x86_64

2010-04-29 Thread Steven Bosscher
2010/4/30 Jan Hubicka : > Yep, I read that page (and saw some of implementation too).  Just was not able > to follow the precise feature set of LIPO (i.e. if it gets better SPEC results > than LTO+FDO then why) OK, that's an interesting question. The first question (if...) is something you'll have

Re: ARM Neon Tests Failing on non-Neon Target

2010-04-29 Thread Joseph S. Myers
On Thu, 29 Apr 2010, Joel Sherrill wrote: > Hi, > > I am looking at the arm-rtems test results for the > trunk and noticing that most failures appear to be > for neon tests. > > [j...@rtbf64a gcc]$ grep ^FAIL gcc.log.sent | wc -l > 2203 > [j...@rtbf64a gcc]$ grep ^FAIL gcc.log.sent | grep /neon

Re: GCC-4.5.0 comparison with previous releases and LLVM-2.7 on SPEC2000 for x86/x86_64

2010-04-29 Thread Jan Hubicka
> 2010/4/30 Jan Hubicka : > >> Thanks for the suggestion. Raksit currently is busy with merging trunk > >> changes back to lw-ipo branch which can be a daunting task. After that > >> this can be done.  (Our internal release is based on 4.4). > > > > I must say that LIPO is something I always intend

gcc-4.5-20100429 is now available

2010-04-29 Thread gccadmin
Snapshot gcc-4.5-20100429 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20100429/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches

Re: GCC-4.5.0 comparison with previous releases and LLVM-2.7 on SPEC2000 for x86/x86_64

2010-04-29 Thread Steven Bosscher
2010/4/30 Jan Hubicka : >> Thanks for the suggestion. Raksit currently is busy with merging trunk >> changes back to lw-ipo branch which can be a daunting task. After that >> this can be done.  (Our internal release is based on 4.4). > > I must say that LIPO is something I always intend to look int

Re: GCC-4.5.0 comparison with previous releases and LLVM-2.7 on SPEC2000 for x86/x86_64

2010-04-29 Thread Jan Hubicka
> Thanks for the suggestion. Raksit currently is busy with merging trunk > changes back to lw-ipo branch which can be a daunting task. After that > this can be done. (Our internal release is based on 4.4). I must say that LIPO is something I always intend to look into but didn't seriously find ti

Re: GCC-4.5.0 comparison with previous releases and LLVM-2.7 on SPEC2000 for x86/x86_64

2010-04-29 Thread Jack Howarth
On Thu, Apr 29, 2010 at 12:25:15PM -0400, Vladimir Makarov wrote: > > Currently Graphite gives small improvements on x86 (one exception is > 2% for peak x86 SPECFP2000) and mostly degradation on x86_64 (with > maximum one more than 10% for SPECFP2000 because of big degradations > on mgrid and

Re: GCC-4.5.0 comparison with previous releases and LLVM-2.7 on SPEC2000 for x86/x86_64

2010-04-29 Thread Xinliang David Li
Thanks for the suggestion. Raksit currently is busy with merging trunk changes back to lw-ipo branch which can be a daunting task. After that this can be done. (Our internal release is based on 4.4). David On Thu, Apr 29, 2010 at 2:38 PM, Steven Bosscher wrote: > On Thu, Apr 29, 2010 at 11:27 P

Re: GCC-4.5.0 comparison with previous releases and LLVM-2.7 on SPEC2000 for x86/x86_64

2010-04-29 Thread Jan Hubicka
> I noticed eon's peak options do not include FDO, is that intended? I think it is just bug in page header, but I will double check. Base and peak should match otherwise. Honza

Re: GCC-4.5.0 comparison with previous releases and LLVM-2.7 on SPEC2000 for x86/x86_64

2010-04-29 Thread Steven Bosscher
On Thu, Apr 29, 2010 at 11:27 PM, Jan Hubicka wrote: > It would be interesting to know if same improvement happens with LTO and if > not what LIPO does.  I will unbreak vortex on our tester. Perhaps you can add a LIPO tester? It looks like a very interesting and promising approach. Ciao! Steven

Re: GCC-4.5.0 comparison with previous releases and LLVM-2.7 on SPEC2000 for x86/x86_64

2010-04-29 Thread Xinliang David Li
I noticed eon's peak options do not include FDO, is that intended? David On Thu, Apr 29, 2010 at 2:27 PM, Jan Hubicka wrote: >> Thanks for the comments.  FDO will probably improve SPEC2000 score. >> Although it is not obvious for some tests because the train data sets >> for them are different

Re: GCC-4.5.0 comparison with previous releases and LLVM-2.7 on SPEC2000 for x86/x86_64

2010-04-29 Thread Xinliang David Li
On Thu, Apr 29, 2010 at 2:27 PM, Jan Hubicka wrote: >> Thanks for the comments.  FDO will probably improve SPEC2000 score. >> Although it is not obvious for some tests because the train data sets >> for them are different from the reference data sets and it might >> actually mislead the  compiler.

Re: GCC-4.5.0 comparison with previous releases and LLVM-2.7 on SPEC2000 for x86/x86_64

2010-04-29 Thread Jan Hubicka
BTW we are also tracking SPEC2k6 with and without LTO (not FDO runs) http://gcc.opensuse.org/SPEC/CINT/sb-barbella.suse.de-ai-64/recent.html http://gcc.opensuse.org/SPEC/CINT/sb-barbella.suse.de-head-64-2006/recent.html not all 2k6 tests pass with LTO so it will need a bit care to compare results

Re: GCC-4.5.0 comparison with previous releases and LLVM-2.7 on SPEC2000 for x86/x86_64

2010-04-29 Thread Jan Hubicka
> Thanks for the comments. FDO will probably improve SPEC2000 score. > Although it is not obvious for some tests because the train data sets > for them are different from the reference data sets and it might > actually mislead the compiler. There are several studies on the topic and it is

ARM Neon Tests Failing on non-Neon Target

2010-04-29 Thread Joel Sherrill
Hi, I am looking at the arm-rtems test results for the trunk and noticing that most failures appear to be for neon tests. [j...@rtbf64a gcc]$ grep ^FAIL gcc.log.sent | wc -l 2203 [j...@rtbf64a gcc]$ grep ^FAIL gcc.log.sent | grep /neon/ | wc -l 1986 http://gcc.gnu.org/ml/gcc-testresults/2010-

Re: GCC-4.5.0 comparison with previous releases and LLVM-2.7 on SPEC2000 for x86/x86_64

2010-04-29 Thread Xinliang David Li
Point well put. The benchmark suite should have good mixture of programs with different sizes. SPEC2k programs cluster at the lower end of the spectrum though. David On Thu, Apr 29, 2010 at 12:43 PM, Vladimir Makarov wrote: > Xinliang David Li wrote: >>> >>> Thanks for the comments.  FDO will pr

Re: GCC-4.5.0 comparison with previous releases and LLVM-2.7 on SPEC2000 for x86/x86_64

2010-04-29 Thread Vladimir Makarov
Xinliang David Li wrote: Thanks for the comments. FDO will probably improve SPEC2000 score. Although it is not obvious for some tests because the train data sets for them are different from the reference data sets and it might actually mislead the compiler. FDO is important for optimizations

Re: GCC-4.5.0 comparison with previous releases and LLVM-2.7 on SPEC2000 for x86/x86_64

2010-04-29 Thread Xinliang David Li
>> > > Thanks for the comments.  FDO will probably improve SPEC2000 score. >  Although it is not obvious for some tests because the train data sets for > them are different from the reference data sets and it might actually > mislead the  compiler. > > FDO is important for optimizations where all p

Re: going from SunOS 5/SparcWorks -> Linux/gcc

2010-04-29 Thread Paweł Sikora
On Thursday 29 April 2010 20:35:23 Steven Bosscher wrote: > The standard 1st questions are: > 1) Did you compile with -Wall -Wextra and solve all warnings? > 2) Did you try with -fno-strict-aliasing? for legacy code, the '-fwrapv' could be helpful.

Re: GCC-4.5.0 comparison with previous releases and LLVM-2.7 on SPEC2000 for x86/x86_64

2010-04-29 Thread Vladimir Makarov
Xinliang David Li wrote: On Thu, Apr 29, 2010 at 9:25 AM, Vladimir Makarov wrote: GCC-4.5.0 and LLVM-2.7 were released recently. To understand where we stand after releasing GCC-4.5.0 I benchmarked it on SPEC2000 for x86/x86-64 and posted the comparison of it with the previous GCC releases

Re: going from SunOS 5/SparcWorks -> Linux/gcc

2010-04-29 Thread Steven Bosscher
On Thu, Apr 29, 2010 at 8:25 PM, Brian Hill wrote: > I have an 15-year old C program (which I didn't write) that compiles and > runs fine with SparcWorks cc on Sun SPARC with SunOS 5.10. > > It compiles on CentOS 5 64-bit with gcc 4.1.2 but core dumps all over the > place. > > Switching to 32-bit

going from SunOS 5/SparcWorks -> Linux/gcc

2010-04-29 Thread Brian Hill
I have an 15-year old C program (which I didn't write) that compiles and runs fine with SparcWorks cc on Sun SPARC with SunOS 5.10. It compiles on CentOS 5 64-bit with gcc 4.1.2 but core dumps all over the place. Switching to 32-bit compile doesn't help much. I did as much debugging as I cou

Re: GCC-4.5.0 comparison with previous releases and LLVM-2.7 on SPEC2000 for x86/x86_64

2010-04-29 Thread Xinliang David Li
On Thu, Apr 29, 2010 at 9:25 AM, Vladimir Makarov wrote: >  GCC-4.5.0 and LLVM-2.7 were released recently.  To understand > where we stand after releasing GCC-4.5.0 I benchmarked it on SPEC2000 > for x86/x86-64 and posted the comparison of it with the > previous GCC releases and LLVM-2.7. > >  Eve

Re: GCC-4.5.0 comparison with previous releases and LLVM-2.7 on SPEC2000 for x86/x86_64

2010-04-29 Thread Vladimir Makarov
Vladimir Makarov wrote: Jan Hubicka wrote: Seems like something sensitive for setup. In our daily benchmarking LTO fatster on wupwise (2116 compared to 1600), and facerec is 2003 compared to 2041 (so about the same). http://gcc.opensuse.org/SPEC/CFP/sb-frescobaldi.suse.de-ai-64/list.html ht

Re: GIMPLE Front End (GSOC 2010)

2010-04-29 Thread Manuel López-Ibáñez
On 29 April 2010 19:25, Sandeep Soni wrote: > I added the following page to the wiki. > > http://gcc.gnu.org/wiki/GimpleFrontEnd > > Any comments/suggestions or ideas related to the project are welcome. Hi Sandy, It may be helpful to take a look to wiki pages of previous SoC projects, such as ht

Problem with SSA form usign cgraph_nodes and push_cfun

2010-04-29 Thread Massimo Nazaria
Hi everybody! I am working on a gcc-pass which processes every statement using this code: for (node = cgraph_nodes; node; node = node->next) { if (node->analyzed && cgraph_is_master_clone (node)) { push_cfun (DECL_STRUCT_FUNCTION (node->decl)); FO

GIMPLE Front End (GSOC 2010)

2010-04-29 Thread Sandeep Soni
-- Forwarded message -- From: Diego Novillo Date: Thu, Apr 29, 2010 at 7:05 PM Subject: Re: [LTO] Open items in the ToDo list To: Sandeep Soni Cc: Andi Hellmund Thanks Sandeep.  Could you please add your proposal to the GCC wiki? Creating a new wiki page is fairly easy.  You ad

Re: GCC-4.5.0 comparison with previous releases and LLVM-2.7 on SPEC2000 for x86/x86_64

2010-04-29 Thread Vladimir Makarov
Jan Hubicka wrote: GCC-4.5.0 and LLVM-2.7 were released recently. To understand where we stand after releasing GCC-4.5.0 I benchmarked it on SPEC2000 for x86/x86-64 and posted the comparison of it with the previous GCC releases and LLVM-2.7. Even benchmarking SPEC2000 takes a lot of time on t

Re: GCC-4.5.0 comparison with previous releases and LLVM-2.7 on SPEC2000 for x86/x86_64

2010-04-29 Thread Jan Hubicka
> GCC-4.5.0 and LLVM-2.7 were released recently. To understand > where we stand after releasing GCC-4.5.0 I benchmarked it on SPEC2000 > for x86/x86-64 and posted the comparison of it with the > previous GCC releases and LLVM-2.7. > > Even benchmarking SPEC2000 takes a lot of time on the fastest

Re: LTO question

2010-04-29 Thread Xinliang David Li
On Thu, Apr 29, 2010 at 9:28 AM, Bingfeng Mei wrote: > I turned on -ffunction-sections and compiled with -Os. > The size gain at -O2 is less though. Interesting. Thanks, David > > Bingfeng > >> -Original Message- >> From: Xinliang David Li [mailto:davi...@google.com] >> Sent: 29 April 2

RE: LTO question

2010-04-29 Thread Bingfeng Mei
I turned on -ffunction-sections and compiled with -Os. The size gain at -O2 is less though. Bingfeng > -Original Message- > From: Xinliang David Li [mailto:davi...@google.com] > Sent: 29 April 2010 17:17 > To: Bingfeng Mei > Cc: Richard Guenther; gcc@gcc.gnu.org > Subject: Re: LTO quest

GCC-4.5.0 comparison with previous releases and LLVM-2.7 on SPEC2000 for x86/x86_64

2010-04-29 Thread Vladimir Makarov
GCC-4.5.0 and LLVM-2.7 were released recently. To understand where we stand after releasing GCC-4.5.0 I benchmarked it on SPEC2000 for x86/x86-64 and posted the comparison of it with the previous GCC releases and LLVM-2.7. Even benchmarking SPEC2000 takes a lot of time on the fastest machine I

Re: LTO question

2010-04-29 Thread Xinliang David Li
Just curious, what is the base line size of your comparison? Did you turn on GC (-ffunction-sections -fdata-sections -Wl,--gc-sections)? David On Wed, Apr 28, 2010 at 2:44 AM, Bingfeng Mei wrote: > Thanks, I will check what I can do with collect2. LTO > seems to save 6-9% code size for applicati

gcc 4.5.0 with Graphite - building & testing

2010-04-29 Thread Solar Designer
Hi, I wrote a lengthy wiki page with step-by-step instructions and demos on building/installing/using gcc 4.5.0 with Graphite under a non-root user account (my test system only had gcc 3.4.5 installed). I think those instructions could be useful to some users of gcc, so feel free to copy them or

Re: LTO vs static library archives [was Re: lto1: internal compiler error: in lto_symtab_merge_decls_1, at lto-symtab.c:549]

2010-04-29 Thread Jan Hubicka
> 2010/4/29 Jan Hubicka : > >> Well, we'd then need to re-architect the symbol merging and > >> LTO unit read-in to properly honor linking semantics (drop > >> a LTO unit from an archive if it doesn't resolve any unresolved > >> symbols).  I don't know how easy that will be, but it shouldn't > >> b

Re: LTO vs static library archives [was Re: lto1: internal compiler error: in lto_symtab_merge_decls_1, at lto-symtab.c:549]

2010-04-29 Thread Richard Guenther
2010/4/29 Jan Hubicka : >> Well, we'd then need to re-architect the symbol merging and >> LTO unit read-in to properly honor linking semantics (drop >> a LTO unit from an archive if it doesn't resolve any unresolved >> symbols).  I don't know how easy that will be, but it shouldn't >> be impossible

GCC viewcvs issue

2010-04-29 Thread Jie Zhang
This URL http://gcc.gnu.org/viewcvs/branches/gcc-4_4-branch/gcc/tree-ssa-alias.c?annotate=155646 which tries to annotate the latest revision of tree-ssa-alias.c on 4.4 branch gives An Exception Has Occurred Python Traceback Traceback (most recent call last): File "/usr/lib/python2.3/site-p

Re: GCC 4.4.4 Release Candidate available from gcc.gnu.org

2010-04-29 Thread Rainer Orth
Jakub Jelinek writes: > The branch is now frozen and all checkins until after the final release > of GCC 4.4.4 require explicit RM approval. > > If all goes well, I'd like to release 4.4.4 next week. I've got a couple of patches I might backport to the 4.4 branch after it is unfrozen again, but

Re: LTO vs static library archives [was Re: lto1: internal compiler error: in lto_symtab_merge_decls_1, at lto-symtab.c:549]

2010-04-29 Thread Ian Lance Taylor
Richard Guenther writes: > Well, we'd then need to re-architect the symbol merging and > LTO unit read-in to properly honor linking semantics (drop > a LTO unit from an archive if it doesn't resolve any unresolved > symbols). I don't know how easy that will be, but it shouldn't > be impossible a

Re: LTO vs static library archives [was Re: lto1: internal compiler error: in lto_symtab_merge_decls_1, at lto-symtab.c:549]

2010-04-29 Thread Jan Hubicka
> Well, we'd then need to re-architect the symbol merging and > LTO unit read-in to properly honor linking semantics (drop > a LTO unit from an archive if it doesn't resolve any unresolved > symbols). I don't know how easy that will be, but it shouldn't > be impossible at least. We also should ke

Re: pattern "s_" not used when generating rtl for float comparison on mips?

2010-04-29 Thread Amker.Cheng
> Indeed, looking at GCC 4.5 there's no cstore expander for floating-point > variables.  Maybe you can make a patch! :-) > yes, it seems gcc always generates set/compare/jump/set sequence, then optimizes it out in if-convert pass. Maybe it was left behind by early mips1, which has no conditional mo

Re: LTO vs static library archives [was Re: lto1: internal compiler error: in lto_symtab_merge_decls_1, at lto-symtab.c:549]

2010-04-29 Thread Richard Guenther
On Thu, Apr 29, 2010 at 11:19 AM, Steven Bosscher wrote: > On Thu, Apr 29, 2010 at 10:57 AM, Richard Guenther > wrote: >> Yes - that would be basically a linker plugin without plugin support. >> And I'd go even further and have LD provide a complete symbol >> resolution set like we get from the g

Re: LTO vs static library archives [was Re: lto1: internal compiler error: in lto_symtab_merge_decls_1, at lto-symtab.c:549]

2010-04-29 Thread Steven Bosscher
On Thu, Apr 29, 2010 at 10:57 AM, Richard Guenther wrote: > Yes - that would be basically a linker plugin without plugin support. > And I'd go even further and have LD provide a complete symbol > resolution set like we get from the gold linker-plugin. > > That wouldn't help for old or non-gnu LDs

Re: LTO question

2010-04-29 Thread Jan Hubicka
> 2010/4/29 Jan Hubicka : > >> > On 4/28/10 10:26 , Manuel López-Ibá?ez wrote: > >> > Not yet, I mistakenly thought -fwhole-program is the same as -fwhopr > >> > and it is just for solving scaling issue of large program.(These two > >> > options do look similar :-). I shall try next.

Re: LTO vs static library archives [was Re: lto1: internal compiler error: in lto_symtab_merge_decls_1, at lto-symtab.c:549]

2010-04-29 Thread Richard Guenther
On Thu, Apr 29, 2010 at 6:11 AM, Dave Korn wrote: > On 26/04/2010 10:46, Richard Guenther wrote: >> On Mon, Apr 26, 2010 at 4:25 AM, Dave Korn wrote: > >>>  If I understand correctly, what we farm out to gold/lto-plugin is the task >>> of identifying a) which archive members are required to be pul

Re: LTO question

2010-04-29 Thread Richard Guenther
2010/4/29 Jan Hubicka : >> > On 4/28/10 10:26 , Manuel López-Ibá?ez wrote: >> > Not yet, I mistakenly thought -fwhole-program is the same as -fwhopr >> > and it is just for solving scaling issue of large program.(These two >> > options do look similar :-). I shall try next. >> > >>>

Re: Why not contribute? (to GCC)

2010-04-29 Thread Paolo Bonzini
On 04/28/2010 12:33 AM, Alfred M. Szmidt wrote: 1) The back-and-forth is too much for casual contributors. If it is more effort to do the legal work than to submit the first patch, then they will never submit any patch at all. Please do not exaggerate, if people have time for threads