public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* Re: egcs: A new compiler project to merge the existing GCC forks (fwd)
@ 1997-08-19 17:18 Joern Rennecke
  1997-08-19 17:18 ` egcs: A new compiler project to merge the existing GCC forks Dave Love
  1997-08-19 17:31 ` Hello, Contrib Back end Jeffrey A Law
  0 siblings, 2 replies; 7+ messages in thread
From: Joern Rennecke @ 1997-08-19 17:18 UTC (permalink / raw)
  To: egcs

>   In message <Pine.GSO.3.96.970819004905.4653A-100000@drabble>you write:
>   > can old scheduler be the source of the problem?
> Could be -- I don't think gcc-2.7* scheduled instructions on the
> x86 machines at all.
> 
> So, one interesting test would be to run the benchmark with "-O2",
> then again with "-O2 -fno-schedule-insns -fno-schedule-insns2".
> 
> That would tell us if we need to focus on the scheduler or not.

And if you look for the best performance right now, I suggest to try
-O2 -fno-schedule-insns .  Scheduling after reload can't hurt register
allocation, and it might do some good.  OTOH, it can hurt when it
disables peepholes.  It's a bity we don't have any actual peephole
optimization pass - combine.c works before reload and is limited in the
number and kind of insns it can combine, and the peepholes used by final
don't allow re-iteration and are not designed to recognize insns sequences
with some unrelated insns in-between.

^ permalink raw reply	[flat|nested] 7+ messages in thread
* Re: egcs: A new compiler project to merge the existing GCC forks
@ 1997-08-19 17:54 H.J. Lu
  0 siblings, 0 replies; 7+ messages in thread
From: H.J. Lu @ 1997-08-19 17:54 UTC (permalink / raw)
  To: egcs

> 
> >  I got a different result. I usedd -O6 for all. f2c + gcc
> >  2.7.2.1 and f2c + egcs 970814 are the same. They got 43
> >  seconds on my PentiumPro 150MHz OC to 166MHz running
> >  Linux 2.0.30. For g77 0.5.21-19970811 in egcs 970814, it
> >  was about 57 seconds. I am not sure if g77 uses the same
> >  options as gcc does.
> 
> The highest g77 entry in the list (because nobody with an Alpha  
> bothered to send anything in) is:
> 
> PentiumPro 200MHz/256K cache, Linux, g77 0.5.18+gcc 2.7.2 [*] .  
> 29.6 s  25Apr97
> PentiumPro 200MHz/256K cache, Linux, g77 0.5.18+gcc 2.7.2 [^] .  
> 33.0 s  25Apr97
> [*]  as [^], plus -fstrength-reduce -fthread-jumps -mno-ieee-fp
> [^]  -O3 -malign-double -funroll-all-loops -fomit-frame-pointer
>      -ffast-math
> 
> so 43 seconds on an (effectively 166 Mhz machine) seem rather low to me

With -O3 -malign-double -funroll-all-loops -fomit-frame-pointer
-ffast-math -fstrength-reduce -fthread-jumps -mno-ieee-fp, I got

35.25 s for egcs 970814 + f2c.
41.78 s for g77 in egcs 970814.

I think that is right in line. BTW, I got signal 11 when I added
-march=i686.


-- 
H.J. Lu (hjl@gnu.ai.mit.edu)

^ permalink raw reply	[flat|nested] 7+ messages in thread
* Re: Some Haifa scheduler bugs
@ 1997-08-19 17:54 Jeffrey A Law
  1997-08-19 17:54 ` egcs: A new compiler project to merge the existing GCC forks Toon Moene
  0 siblings, 1 reply; 7+ messages in thread
From: Jeffrey A Law @ 1997-08-19 17:54 UTC (permalink / raw)
  To: egcs

  In message <Pine.SOL.3.90.970819092828.291B-100000@starsky.informatik.rwth-aa
chen.de>you write:
  > I've run c-torture on the egcs snapshot, using the Haifa scheduler with
  > all flags turned on. My system is an i586-linux one. Here's a patch to fix
  > some of the failures.
Thanks.

Just some comments:

  * Get a copyright assignment + disclaimer signed and sent to
  the FSF as soon as possible.  Until that time we can't take any
  of your patches and include them without rewriting them first.

  * When submitting patches, send separate patches for bugs from
  random cleanups.  The cleanups are greatly appreciated, especially
  for haifa.

  * When submitting bugfix patches, please submit a testcase, or
  refer us to a c-torture testcase and the options needed to expose
  the bug.


Specific questions/comments:

In move_insn, is there some reason why you can't call reemit_notes
during the loop on SCHED_GROUP_P insns?

ie, does this work instead?  Seems cleaner than using another loop
if it works.

{
  rtx new_last = insn;

  while (SCHED_GROUP_P (insn))
    {
      rtx prev = PREV_INSN (insn);
      move_insn1 (insn, last);
      reemit_notes (insn, insn);
      insn = prev;
    }

  move_insn1 (insn, last);
  return reemit_notes (new_last, new_last);
}

[ Of course if you had referred us to a testcase, we could check
  this ourselves.... ]

Jeff

^ permalink raw reply	[flat|nested] 7+ messages in thread
* Re: egcs: A new compiler project to merge the existing GCC forks
@ 1997-08-19 16:06 H.J. Lu
  0 siblings, 0 replies; 7+ messages in thread
From: H.J. Lu @ 1997-08-19 16:06 UTC (permalink / raw)
  To: egcs

> 
> 
> I downloaded this a few days ago - compiles and runs without any
> problems on a PentiumPro Linux 2.0.30 (Redhat 4.2) system - but:
> 
> execution speed (floating point) of a test case (mdbench) compiled
> with f2c+gcc is about 10% slower than using gcc 2.7.2.1 - it is
> about the same or very slighly faster than g77 0.5.19.1 when using
> g77 0.5.21 - when using single precision both f2c+gcc and g77 are
> about 10-25% slower than their gcc 2.7.2.1/g77 0.5.19.1 counter-
> parts.
> 
> I had hoped that performance would improve rather than get worse -
> is it so hard to optimize for x86? - I am back right now to the old
> stuff, unless I get to hear a convincing reason why to switch.

Here is some good news. I used:

# gcc -O6 -o egcs.O6 mdbnch.c -lf2c -lm -march=i686

Now the runtime was reduced from 43 seconds to about 39.5 seconds.
FYI, the Pentium Pro (i686) switch is only available in egcs.
If you compile your libf2c.a in egcs with -march=i686 -O6, you
may get even more performance boost. Further more, we are working on
new x86 floating point performance enhancement in egcs. It should
be available soon.


-- 
H.J. Lu (hjl@gnu.ai.mit.edu)

^ permalink raw reply	[flat|nested] 7+ messages in thread
* Re: egcs: A new compiler project to merge the existing GCC forks
@ 1997-08-19 15:01 H.J. Lu
  0 siblings, 0 replies; 7+ messages in thread
From: H.J. Lu @ 1997-08-19 15:01 UTC (permalink / raw)
  To: egcs

> 
> 
> I downloaded this a few days ago - compiles and runs without any
> problems on a PentiumPro Linux 2.0.30 (Redhat 4.2) system - but:
> 
> execution speed (floating point) of a test case (mdbench) compiled
> with f2c+gcc is about 10% slower than using gcc 2.7.2.1 - it is
> about the same or very slighly faster than g77 0.5.19.1 when using
> g77 0.5.21 - when using single precision both f2c+gcc and g77 are
> about 10-25% slower than their gcc 2.7.2.1/g77 0.5.19.1 counter-
> parts.
> 
> I had hoped that performance would improve rather than get worse -
> is it so hard to optimize for x86? - I am back right now to the old
> stuff, unless I get to hear a convincing reason why to switch.
> 

I got a different result. I usedd -O6 for all. f2c + gcc 2.7.2.1 and
f2c + egcs 970814 are the same. They got 43 seconds on my PentiumPro
150MHz OC to 166MHz running Linux 2.0.30. For g77 0.5.21-19970811 in
egcs 970814, it was about 57 seconds. I am not sure if g77 uses the
same options as gcc does.

BTW, do you know egcs 970814 comes with its own libf2c.a. Are you
sure both gcc 2.7.2.1 and egcs 970814 use the same libf2c.a?

I did:

# f2c -A mdbnch.f
# gcc-2.7.2.1  -O6 -c mdbnch.c
# gcc  -O6 -o 2.7.2.1.O6 mdbnch.o -lf2c -lm
# gcc  -O6 -o egcs.O6 mdbnch.c -lf2c -lm

So that the same libf2c.a from egcs 970814 is used.


-- 
H.J. Lu (hjl@gnu.ai.mit.edu)

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~1997-08-19 17:54 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1997-08-19 17:18 egcs: A new compiler project to merge the existing GCC forks (fwd) Joern Rennecke
1997-08-19 17:18 ` egcs: A new compiler project to merge the existing GCC forks Dave Love
1997-08-19 17:31 ` Hello, Contrib Back end Jeffrey A Law
  -- strict thread matches above, loose matches on Subject: below --
1997-08-19 17:54 egcs: A new compiler project to merge the existing GCC forks H.J. Lu
1997-08-19 17:54 Some Haifa scheduler bugs Jeffrey A Law
1997-08-19 17:54 ` egcs: A new compiler project to merge the existing GCC forks Toon Moene
1997-08-19 16:06 H.J. Lu
1997-08-19 15:01 H.J. Lu

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).