Re: Some Haifa scheduler bugs

Re: Some Haifa scheduler bugs

[Jeffrey A Law]

  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

Re: egcs: A new compiler project to merge the existing GCC forks

[Toon Moene]

>  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

Cheers,
Toon.

Re: egcs: A new compiler project to merge the existing GCC forks (fwd)

[Dave Love]

>>>>> "Jeffrey" == Jeffrey A Law <law@hurl.cygnus.com> writes:

 Jeffrey> Could be -- I don't think gcc-2.7* scheduled instructions on
 Jeffrey> the x86 machines at all.

FWIW, the last gcc2 snapshot I could build (with -m586 in) typically
seemed to gain about 20% on a 586 with single-precision Fortran code,
roughly consistent with numbers reported by proprietary offerings at
the time, though some with `pentium optimization' only seemed to
perform about as well as the gcc-2.7-based g77 (generating 486 code).

If people care about Fortran performance I'll eventually do some
realistic tests on a 586, but have no access to a 686; this isn't
necessarily trivial, though, and I'm more interested in the release of
a correct g77 0.5.21 at this stage.

Re: egcs: A new compiler project to merge the existing GCC forks (fwd)

[Joern Rennecke]

>   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.

Re: egcs: A new compiler project to merge the existing GCC forks (fwd)

[H.J. Lu]

> 
> 
> HJ, can you work with this person to find out _why_ performance
> is suffering?
> 

I am still working on prototyping. But if noone is looking at it,
I will take a look.


H.J.

Re: Reload patch to improve 386 code

[Jakub Jelinek]

> 
>    Date: Mon, 18 Aug 1997 11:17:38 -0400 (EDT)
>    From: meissner@cygnus.com
> 
>    I think it is an horrible kludge that reload is run as a pass after
>    global-alloc, and that it forces reload registers not to be used
>    for any other purpose (which is murder on the x86 with each
>    register being special purpose in some way).
> 
> Before this leaves my head, I wanted to point something out which
> you've reminded me of.  When the scheduler (this applies to both the
> original and Haifa versions equally) becomes aggressive, it produces a
> large number of reloads in certain situations.  Reloads which would
> not have happened if scheduling did not take place.  This happens
> especially if register pressure is high already.  I noticed this
> particularly on RISC platforms, seems in this case the more registers
> available the worse things became when the register usage was
> saturated.

I thought about a quick solution, which would be during global-alloc, if it
finds out that the number of hard registers is exceeded, it could try to
undo some short pseudo setup RTL sequence merges and move them to the place
of the actual use, if the pseudo being set up is a constant and computable
in small number of instructions not involving memory loads.
Like that, we could rid of the following horror on sparc64:

	sethi %hi(var1), %r1
	stx %r1, [%sp + NN]
	...
	ldx [%sp + NN], %r1
	or %r1, %lo(var1), %r1
	stx %r1, [%sp + NN]
	...
some loop:
	...
	ldx [%sp + NN], %r1
	ldx [%r1], %r1
	...

and could have:

some loop:
	...
	sethi %hi(var1), %r1
	ldx [%r1 + %lo(var1)], %r1
	...

instead...

Cheers,
    Jakub
___________________________________________________________________
Jakub Jelinek | jj@sunsite.mff.cuni.cz | http://sunsite.mff.cuni.cz
Administrator of SunSITE Czech Republic, MFF, Charles University
___________________________________________________________________
Ultralinux - first 64bit OS to take fool power from the UltraSparc
Linux version 2.0.30 on a sparc machine (291.64 BogoMips).
___________________________________________________________________

Re: egcs: A new compiler project to merge the existing GCC forks (fwd)

[Dave Love]

>>>>> "H" == H J Lu <hjl@lucon.org> writes:

 H> I downloaded this a few days ago - compiles and runs without any
 H> problems on a PentiumPro Linux 2.0.30 (Redhat 4.2) system - but:

 H> execution speed (floating point) of a test case (mdbench) 

Note that mdbnch (at least the version I know) is in double precision.
Thus other performance considerations are typically overshadowed on
ppro by the double alignment problems.  See the g77 manual.

 H>  - I am back right now to the old
 H> stuff, unless I get to hear a convincing reason why to switch.

I doubt it's wise to use the g77 in egcs seriously at least until it's
based on a version that's completed alpha testing for g77 0.5.21.

Re: egcs: A new compiler project to merge the existing GCC forks (fwd)

[Robert Wilhelm]

> 
> Can someone point me the location of mdbench?
>

http://www.sissa.it/furio/Mdbnch/info.html

Robert

egcs: A new compiler project to merge the existing GCC forks (fwd)

[H.J. Lu]

Forwarded message:
Date: Tue, 19 Aug 1997 11:09:07 +0900
From: Arno PAHLER <paehler@atlas.rc.m-kagaku.co.jp>
Message-Id: <199708190209.LAA04886@atlas.rc.m-kagaku.co.jp>
To: "H.J. Lu" <hjl@lucon.org>
In-reply-to: "H.J. Lu"'s message of Sun, 17 Aug 1997 09:12:40 -0700
Subject: egcs: A new compiler project to merge the existing GCC forks


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.


Arno


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

Re: egcs: A new compiler project to merge the existing GCC forks (fwd)

[Jeffrey A Law]

HJ, can you work with this person to find out _why_ performance
is suffering?

If nobody takes the time to analyze these problems, then performance
is never going to get significantly better.

  In message <m0x0fih-0004ecC@ocean.lucon.org>you write:
  > Forwarded message:
  > >From paehler@atlas.rc.m-kagaku.co.jp Mon Aug 18 19:09:18 1997
  > Date: Tue, 19 Aug 1997 11:09:07 +0900
  > From: Arno PAHLER <paehler@atlas.rc.m-kagaku.co.jp>
  > Message-Id: <199708190209.LAA04886@atlas.rc.m-kagaku.co.jp>
  > To: "H.J. Lu" <hjl@lucon.org>
  > In-reply-to: "H.J. Lu"'s message of Sun, 17 Aug 1997 09:12:40 -0700
  > Subject: egcs: A new compiler project to merge the existing GCC forks
  > 
  > 
  > 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.
  > 
  > 
  > Arno
  > 
  > 
  > -- 
  > H.J. Lu (hjl@gnu.ai.mit.edu)

Re: egcs: A new compiler project to merge the existing GCC forks (fwd)

[Oleg Krivosheev]

  Hi,

On Mon, 18 Aug 1997, Jeffrey A Law wrote:

> HJ, can you work with this person to find out _why_ performance
> is suffering?
> 
> If nobody takes the time to analyze these problems, then performance
> is never going to get significantly better.

can old scheduler be the source of the problem?
i was able to figure out switch --enable-haifa
only looking into ./configure script. New scheduler
is off  by default.

Can someone point me the location of mdbench?

i'll benchmark it...

regards

OK

> 
>   In message <m0x0fih-0004ecC@ocean.lucon.org>you write:
>   > Forwarded message:
>   > >From paehler@atlas.rc.m-kagaku.co.jp Mon Aug 18 19:09:18 1997
>   > Date: Tue, 19 Aug 1997 11:09:07 +0900
>   > From: Arno PAHLER <paehler@atlas.rc.m-kagaku.co.jp>
>   > Message-Id: <199708190209.LAA04886@atlas.rc.m-kagaku.co.jp>
>   > To: "H.J. Lu" <hjl@lucon.org>
>   > In-reply-to: "H.J. Lu"'s message of Sun, 17 Aug 1997 09:12:40 -0700
>   > Subject: egcs: A new compiler project to merge the existing GCC forks
>   > 
>   > 
>   > 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.
>   > 
>   > 
>   > Arno
>   > 
>   > 
>   > -- 
>   > H.J. Lu (hjl@gnu.ai.mit.edu)
> 

                                     Oleg Krivosheev, 
                                     MS 345, AD/Physics,
                                     Fermi National Accelerator Laboratory,
                                     P.O.Box 500, Batavia, Illinois, 60510.
                                     phone: (630) 840 8460
                                     FAX  : (630) 840 4552
                                     Email: kriol@fnal.gov

Re: egcs: A new compiler project to merge the existing GCC forks (fwd)

[Jeffrey A Law]

  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.


seem like haifa could help the pentium pro, however the i386.md
file would have to be tweaked to get the best performance out of
haifa.

Jeff