Re: [BusyBox] Re: Long term code compactness regression

Re: [BusyBox] Re: Long term code compactness regression

[mike stump]

> Date: Sun, 28 Oct 2001 19:54:15 +0100
> From: Paolo Carlini <pcarlini@unitus.it>
> To: Jan Hubicka <jh@suse.cz>
> CC: gcc@gcc.gnu.org

> Jan, sorry for my pedantry, but I have ready at hand a very short
> and basic c++ testcode (reduced from the Haney tests) which today is
> 2 times (!) slower than one week ago on i686 (-O2)... Do you have
> time to look a little bit at it? Here it is (PR4714 for some more
> details):

Have you binary searched the changes and identified the change that
blew performance?  If not, that would be a big help in identifying
what went wrong.  If you have, it helps to name the patch that blew
performance in this type of email.

Re: [BusyBox] Re: Long term code compactness regression

[Jan Hubicka]

> > Date: Sun, 28 Oct 2001 19:54:15 +0100
> > From: Paolo Carlini <pcarlini@unitus.it>
> > To: Jan Hubicka <jh@suse.cz>
> > CC: gcc@gcc.gnu.org
> 
> > Jan, sorry for my pedantry, but I have ready at hand a very short
> > and basic c++ testcode (reduced from the Haney tests) which today is
> > 2 times (!) slower than one week ago on i686 (-O2)... Do you have
> > time to look a little bit at it? Here it is (PR4714 for some more
> > details):
> 
> Have you binary searched the changes and identified the change that
> blew performance?  If not, that would be a big help in identifying
> what went wrong.  If you have, it helps to name the patch that blew
> performance in this type of email.
The slowdown appears to come from the fact that Richard Kenner has fixed
a bug that caused alias code to be bit more aggresive than it can be.

Honza

Alias analysis and C++. Was: Re: [BusyBox] Re: Long term code...

[Paolo Carlini]

Jan Hubicka wrote:

> > Have you binary searched the changes and identified the change that
> > blew performance?  If not, that would be a big help in identifying
> > what went wrong.  If you have, it helps to name the patch that blew
> > performance in this type of email.
> The slowdown appears to come from the fact that Richard Kenner has fixed
> a bug that caused alias code to be bit more aggresive than it can be.
>
> Honza

... more aggressive than it can be... right now! :-)

Seriously, Jan has already made some good progress (excellent!) and I'm
still hoping that this alias analysis issue with C++ will be satisfactorily
solved in time for 3.1: it seems to me that it is not just a matter of
improving the optimization of a short testcase, but something from which
many common loop patterns may appreciably benefit.

What I cannot understand at all at this point is how *much* work is needed,
that is how much infrastructure is already present and only in need of
debugging and refinements, and how much has to be written from scratch...

Cheers,
Paolo Carlini.

Re: Alias analysis and C++. Was: Re: [BusyBox] Re: Long term code...

[Jan Hubicka]

> Seriously, Jan has already made some good progress (excellent!) and I'm
> still hoping that this alias analysis issue with C++ will be satisfactorily
> solved in time for 3.1: it seems to me that it is not just a matter of

Don't rely too much on me in this case.  I've fixed the overhemly conservative
predicate, but it don't help in your testcase, but it helps in others that
do use arrays itself (not hid inside structure).

I understand briefly how the base classes are determined, but there are number
of dificult details most probably behind my experinece in C++ frontend..
Sadly :(

Honza
> improving the optimization of a short testcase, but something from which
> many common loop patterns may appreciably benefit.
> 
> What I cannot understand at all at this point is how *much* work is needed,
> that is how much infrastructure is already present and only in need of
> debugging and refinements, and how much has to be written from scratch...
> 
> Cheers,
> Paolo Carlini.

Re: Alias analysis and C++. Was: Re: [BusyBox] Re: Long term code...

[Paolo Carlini]

Jan Hubicka wrote:

> > Seriously, Jan has already made some good progress (excellent!) and I'm
> > still hoping that this alias analysis issue with C++ will be satisfactorily
> > solved in time for 3.1: it seems to me that it is not just a matter of
>
> Don't rely too much on me in this case.  I've fixed the overhemly conservative
> predicate, but it don't help in your testcase, but it helps in others that
> do use arrays itself (not hid inside structure).

I see. And I would like to add that, as an interested user, I have always
appreciated your valuable and continuos contributions to the middle- and back-end
of the compiler (and your humility, of course)

> I understand briefly how the base classes are determined, but there are number
> of dificult details most probably behind my experinece in C++ frontend..
> Sadly :(

I think this could be a good occasion for me to begin studying in some detail the
C++ front-end. Could you possibly send me privately the patch you have already
prepared as a starting point for my investigations?

Thanks again,
Paolo.

Re: [BusyBox] Re: Long term code compactness regression

[Jan Hubicka]

> Jan Hubicka wrote:
> 
> > > I checked this morning, with last week's gcc-3.1 snapshot.  A few cases
> > > with g77 have slowed down in recent weeks.  The worst examples of
> > In what testcases g77 slowed down recently?
> >
> > Honza
> 
> Jan, sorry for my pedantry, but I have ready at hand a very short and basic
> c++ testcode (reduced from the Haney tests) which today is 2 times (!) slower
> than one week ago on i686 (-O2)... Do you have time to look a little bit at
> it? Here it is (PR4714 for some more details):
Sure!
I will try to figure out what has changed.

Thanks a lot for nice testcase.  I need to read gcc-bugs more curefully.
Honza

Re: [BusyBox] Re: Long term code compactness regression

[Jan Hubicka]

> 
> ----- Original Message -----
> From: "Jan Hubicka" <jh@suse.cz>
> To: "Tim Prince" <tprince@computer.org>
> Cc: "Jan Hubicka" <jh@suse.cz>; "Paolo Carlini" <pcarlini@unitus.it>;
> "David Schleef" <ds@schleef.org>; <gcc@gcc.gnu.org>
> Sent: Sunday, October 28, 2001 10:33 AM
> Subject: Re: [BusyBox] Re: Long term code compactness regression
> 
> 
> > > I checked this morning, with last week's gcc-3.1 snapshot.  A few
> cases
> > > with g77 have slowed down in recent weeks.  The worst examples of
> > In what testcases g77 slowed down recently?
> >
> The Livermore Fortran Kernels 4 and 10 both slowed down more than 15%
> since 6 weeks ago, with gcc-3.1 on my P-III laptop.  Kernel 8 is the
> worst example where -O2 is slower than -Os.  Kernel 10 also is slower
> at -O2.  I'll look more closely at this when I have time.
Richard made some changes to strength reduction.  I guess the analyzis
behaves crazilly that causes strength reduction to do nasty thinks.

I've made some improvements to early dead code removal as side effect
of my webizer pass, but it looks that it will not get in, as it can
get obsoletted by SSA, but thats behind 3.1 horizont...

I will try to compare the difference. 
Thanks for letting me know!

Honza

Re: [BusyBox] Re: Long term code compactness regression

[Paolo Carlini]

Jan Hubicka wrote:

> > I checked this morning, with last week's gcc-3.1 snapshot.  A few cases
> > with g77 have slowed down in recent weeks.  The worst examples of
> In what testcases g77 slowed down recently?
>
> Honza

Jan, sorry for my pedantry, but I have ready at hand a very short and basic
c++ testcode (reduced from the Haney tests) which today is 2 times (!) slower
than one week ago on i686 (-O2)... Do you have time to look a little bit at
it? Here it is (PR4714 for some more details):

///////////////////////////////////////////////
class RealMatrix {
public:

  float &index(int i, int j)
    {
      return d[i - 1 + n[0] * (j - 1)];
    }
  float index(int i, int j) const
    {
      return d[i - 1 + n[0] * (j - 1)];
    }

  int dim(int i) const { return n[i - 1]; }

private:

  float *d;
  int n[4];
};

void rmatMul(RealMatrix &t, const RealMatrix &a, const RealMatrix &b)
{
  const int M = a.dim(1), N = b.dim(2), K = b.dim(1);

  for (int j = 1; j <= N; j++)
    {
      for (int k = 1; k <= K; k++)
        {
          float temp = b.index(k, j);
          if (temp != 0.0)
            {
              for (int i = 1; i <= M; i++)
                t.index(i, j) += temp * a.index(i, k);
            }
        }
    }
}
/////////////////////////////////////////

Thanks,
Paolo.

Re: [BusyBox] Re: Long term code compactness regression

[Tim Prince]

----- Original Message -----
From: "Jan Hubicka" <jh@suse.cz>
To: "Tim Prince" <tprince@computer.org>
Cc: "Jan Hubicka" <jh@suse.cz>; "Paolo Carlini" <pcarlini@unitus.it>;
"David Schleef" <ds@schleef.org>; <gcc@gcc.gnu.org>
Sent: Sunday, October 28, 2001 10:33 AM
Subject: Re: [BusyBox] Re: Long term code compactness regression


> > I checked this morning, with last week's gcc-3.1 snapshot.  A few
cases
> > with g77 have slowed down in recent weeks.  The worst examples of
> In what testcases g77 slowed down recently?
>
The Livermore Fortran Kernels 4 and 10 both slowed down more than 15%
since 6 weeks ago, with gcc-3.1 on my P-III laptop.  Kernel 8 is the
worst example where -O2 is slower than -Os.  Kernel 10 also is slower
at -O2.  I'll look more closely at this when I have time.

Re: [BusyBox] Re: Long term code compactness regression

[Jan Hubicka]

> I checked this morning, with last week's gcc-3.1 snapshot.  A few cases
> with g77 have slowed down in recent weeks.  The worst examples of
In what testcases g77 slowed down recently?

Honza
> slowness with g77 -O2 involve the generation of redundant pointers, as we
> have discussed before.  I see -Os faster than -O2 in the same tests
> on -msse2 and on -march=pentiumpro.

Re: [BusyBox] Re: Long term code compactness regression

[Tim Prince]

----- Original Message -----
From: "Jan Hubicka" <jh@suse.cz>
To: "Tim Prince" <tprince@computer.org>
Cc: "Paolo Carlini" <pcarlini@unitus.it>; "David Schleef"
<ds@schleef.org>; <gcc@gcc.gnu.org>
Sent: Sunday, October 28, 2001 9:08 AM
Subject: Re: [BusyBox] Re: Long term code compactness regression


> > So, will we retain the option of setting an aligned stack along
with -Os
> Not.
> currently the mainline contains patch to default stack alignment to 2
if
> -Os is present I am not quite happy about.
> You can still pass -Os and overwrite the alignment
by -mpreferred-stack-bodary=4
> > ?  On most of my applications, -Os together with -funroll-loops and
> > aligned data is the fastest running combination for ia32, by a large
> > margin.
> Do you have any idea why this happends? We should really keep -O2
faster
> than -Os in most cases.
> I've done some work on the mainline to avoid code bloat in -O2 mode, so
> maybe the score is better now.
>
> Honza

I checked this morning, with last week's gcc-3.1 snapshot.  A few cases
with g77 have slowed down in recent weeks.  The worst examples of
slowness with g77 -O2 involve the generation of redundant pointers, as we
have discussed before.  I see -Os faster than -O2 in the same tests
on -msse2 and on -march=pentiumpro.

Re: [BusyBox] Re: Long term code compactness regression

[Jan Hubicka]

> So, will we retain the option of setting an aligned stack along with -Os
Not.
currently the mainline contains patch to default stack alignment to 2 if
-Os is present I am not quite happy about.
You can still pass -Os and overwrite the alignment by -mpreferred-stack-bodary=4
> ?  On most of my applications, -Os together with -funroll-loops and
> aligned data is the fastest running combination for ia32, by a large
> margin.
Do you have any idea why this happends? We should really keep -O2 faster
than -Os in most cases.
I've done some work on the mainline to avoid code bloat in -O2 mode, so
maybe the score is better now.

Honza

Re: [BusyBox] Re: Long term code compactness regression

[Tim Prince]

So, will we retain the option of setting an aligned stack along with -Os
?  On most of my applications, -Os together with -funroll-loops and
aligned data is the fastest running combination for ia32, by a large
margin.
----- Original Message -----
From: "Paolo Carlini" <pcarlini@unitus.it>
To: "David Schleef" <ds@schleef.org>
Cc: <gcc@gcc.gnu.org>
Sent: Sunday, October 28, 2001 5:11 AM
Subject: Re: [BusyBox] Re: Long term code compactness regression


> David Schleef wrote:
>
> > On Sat, Oct 27, 2001 at 02:20:26AM -0700, Aaron Lehmann wrote:
> > > On Fri, Oct 26, 2001 at 05:35:30PM -0700, Aaron Lehmann wrote:
> > > > 3.0.2                       -O2 -mpreferred-stack-boundary=2
212844
> > > > 2.95.4-pre          -O2 -mpreferred-stack-boundary=2
204076
> > > > HEAD                        -O2 -mpreferred-stack-boundary=2
202616
> > >
> > > s/-O2/-Os/ for all of these. Whoops.
> > >
> >
> > This raises the question: why doesn't -Os imply
> > -mpreferred-stack-boundary=2?
>
> It will in 3.1, see this recent checkin by Alexandre Oliva:
>
>     http://gcc.gnu.org/ml/gcc-cvs/2001-10/msg00511.html
>
> Cheers,
> Paolo.
>
>

Re: [BusyBox] Re: Long term code compactness regression

[Paolo Carlini]

David Schleef wrote:

> On Sat, Oct 27, 2001 at 02:20:26AM -0700, Aaron Lehmann wrote:
> > On Fri, Oct 26, 2001 at 05:35:30PM -0700, Aaron Lehmann wrote:
> > > 3.0.2                       -O2 -mpreferred-stack-boundary=2        212844
> > > 2.95.4-pre          -O2 -mpreferred-stack-boundary=2        204076
> > > HEAD                        -O2 -mpreferred-stack-boundary=2        202616
> >
> > s/-O2/-Os/ for all of these. Whoops.
> >
>
> This raises the question: why doesn't -Os imply
> -mpreferred-stack-boundary=2?

It will in 3.1, see this recent checkin by Alexandre Oliva:

    http://gcc.gnu.org/ml/gcc-cvs/2001-10/msg00511.html

Cheers,
Paolo.

Re: [BusyBox] Re: Long term code compactness regression

[David Schleef]

On Sat, Oct 27, 2001 at 02:20:26AM -0700, Aaron Lehmann wrote:
> On Fri, Oct 26, 2001 at 05:35:30PM -0700, Aaron Lehmann wrote:
> > 3.0.2			-O2 -mpreferred-stack-boundary=2	212844
> > 2.95.4-pre		-O2 -mpreferred-stack-boundary=2	204076
> > HEAD			-O2 -mpreferred-stack-boundary=2	202616
> 
> s/-O2/-Os/ for all of these. Whoops.
> 

This raises the question: why doesn't -Os imply
-mpreferred-stack-boundary=2?



dave...