[tree-ssa] Merge status

[tree-ssa] Merge status

[Diego Novillo]

Build
-----

The branch is in sync with mainline as of 2003-03-07.  It bootstraps
daily alphaev67-unknown-linux-gnu, i686-pc-linux-gnu,
x86_64-unknown-linux-gnu, powerpc-unknown-linux-gnu and
ia64-unknown-linux-gnu.

I've tried bootstrapping on sparc-sun-solaris2.8 but the machine is too
small for libjava and runs out of memory running 'ar'.  The compiler
bootstrapped, but I know there are outstanding sparc patches for it. 
I'd appreciate if someone with a beefier machine could try it out
together with Christian Ehrhardt's patch
http://gcc.gnu.org/ml/gcc-patches/2004-02/msg02716.html (which needs a
sparc or global maintainer to look over it).

Builds on mn10300-elf are currently underway.  I will post to
gcc-testresults as soon as the build finishes.  So far, I haven't seen
any problems.


Documentation
-------------

There is new high-level documentation in doc/tree-ssa.texi and
doc/passes.texi.  Still not all there, but it's being populated.
All of the -f and --parm switches should already be documented.

If you are going over the implementation and find missing things, please
update PR 13756.


Application testing
-------------------

We have been building FC2 with the tree-ssa compiler.  We can build 739
packages and fail to build 176 packages (build pass rate of 80.7%). 
About 20 failures are related to tree-ssa, ~30 are cast-as-lvalue
extensions and the rest are still to be determined.

There are 22 tree-ssa specific bugs.  The major obstacles are the memory
and compile time regressions in C++.  To get a list of all the bugs go
to: http://tinyurl.com/28b2b


SPEC testing
------------

For SPEC2000int, the branch is 2% behind mainline on x86.  For
SPEC2000fp, the branch is 0.4% ahead.  I will post x86-64 resuts soon.


Compile Time Performance
------------------------

This is the major piece of work that we would like to address before the
merge.

Currently, bootstrap times on the branch are 14% slower than mainline
when configured with

    --disable-libmudflap --without-libbanshee --disable-checking
    --enable-languages=c,c++,java,objc

Work is underway to remove some RTL passes and figure out how to speed
up POOMA, DLV, MICO, etc.  PR 13776 is the place holder for all the
compile time and memory consumption regressions.  Once we fix these, we
should be ready to merge.


Diego.

Re: [tree-ssa] Merge status

[Diego Novillo]

On Fri, 2004-03-12 at 19:07, Diego Novillo wrote:

> There are 22 tree-ssa specific bugs.  The major obstacles are the memory
> and compile time regressions in C++.  To get a list of all the bugs go
> to: http://tinyurl.com/28b2b
> 
Sorry.  That should be http://tinyurl.com/32paa


Diego.

Re: [tree-ssa] Merge status

[Andreas Jaeger]

[-- Attachment #1: Type: text/plain, Size: 652 bytes --]

Diego Novillo <dnovillo@redhat.com> writes:

> Build
> -----
>
> The branch is in sync with mainline as of 2003-03-07.  It bootstraps
> daily alphaev67-unknown-linux-gnu, i686-pc-linux-gnu,
> x86_64-unknown-linux-gnu, powerpc-unknown-linux-gnu and
> ia64-unknown-linux-gnu.

I've additionally bootstrapped the current branch successfully on
s390-ibm-linux-gnu and powerpc64-suse-linux-gnu.  I'm currently
building on s390x-ibm-linux-gnu...

Andreas
-- 
 Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj
  SuSE Linux AG, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: [tree-ssa] Merge status

[Andrew Pinski]

On Mar 12, 2004, at 16:07, Diego Novillo wrote:

>
> Build
> -----
>
> The branch is in sync with mainline as of 2003-03-07.  It bootstraps
> daily alphaev67-unknown-linux-gnu, i686-pc-linux-gnu,
> x86_64-unknown-linux-gnu, powerpc-unknown-linux-gnu and
> ia64-unknown-linux-gnu.

The tree-ssa also bootstraps on powerpc-apple-darwin7.2.0 with no 
problem.
I will send the testresults when I get time to rebootstrap it (as I 
already
removed the objdir).


Thanks,
Andrew Pinski

Re: [tree-ssa] Merge status

[Andreas Tobler]

Diego Novillo wrote:
> Build
> -----
> 
> The branch is in sync with mainline as of 2003-03-07.  It bootstraps
> daily alphaev67-unknown-linux-gnu, i686-pc-linux-gnu,
> x86_64-unknown-linux-gnu, powerpc-unknown-linux-gnu and
> ia64-unknown-linux-gnu.
> 
> I've tried bootstrapping on sparc-sun-solaris2.8 but the machine is too
> small for libjava and runs out of memory running 'ar'.  The compiler
> bootstrapped, but I know there are outstanding sparc patches for it. 
> I'd appreciate if someone with a beefier machine could try it out
> together with Christian Ehrhardt's patch
> http://gcc.gnu.org/ml/gcc-patches/2004-02/msg02716.html (which needs a
> sparc or global maintainer to look over it).

Here sparc-sun-solaris2.9 (32-bit) bootstraps ok, no patches needed. 
c,c++,java.

Results are coming soon.

Andreas

Re: [tree-ssa] Merge status

[Eric Botcazou]

> I've tried bootstrapping on sparc-sun-solaris2.8 but the machine is too
> small for libjava and runs out of memory running 'ar'.  The compiler
> bootstrapped, but I know there are outstanding sparc patches for it.
> I'd appreciate if someone with a beefier machine could try it out
> together with Christian Ehrhardt's patch
> http://gcc.gnu.org/ml/gcc-patches/2004-02/msg02716.html (which needs a
> sparc or global maintainer to look over it).

I don't think the sparc.md patch is correct.

-- 
Eric Botcazou

Re: [tree-ssa] Merge status

[David Edelsohn]

	powerpc-ibm-aix5.1.0.0 bootstraps with no problem and results are
being posted to gcc-testresults regularly.

David

Re: [tree-ssa] Merge status

[Nathanael Nerode]

>The branch is in sync with mainline as of 2003-03-07.
                                              ^
I sincerely hope you meant 2004.  ;-)

-- 
Make sure your vote will count.
http://www.verifiedvoting.org/

Re: [tree-ssa] Merge status

[Jan Hubicka]

> > For SPEC2000int, the branch is 2% behind mainline on x86.  For
> > SPEC2000fp, the branch is 0.4% ahead.  I will post x86-64 resuts soon.
> 
> Are the performance problems on SPEC2000int (and the improvements in
> SPEC2000fp) concentrated in a single test?
> 
> > Currently, bootstrap times on the branch are 14% slower than mainline
> > [...] Work is underway to remove some RTL passes
> 
> It may be interesting to try without ADDRESSOF; I cannot test it fully but I
> made some experiments; I simply tweaked function.c to not generate it, but Jan
> has posted a polished patch which AFAIK is still waiting for review.  I
> successfully bootstrapped mainline without all three of ADDRESSOF generation,
> CSE1 (oh yeah) and the small purge_addressof pass.  This helps bootstrapping
> time, but somebody should do SPEC tests to see if it causes performance
> problems for the other merge criterion -- with Jan's patch, the necessary
> modification is as easy as emptying rest_of_handle_cse and
> rest_of_handle_addressof.

Problem of the ADDRESSOF patch is that it cause seriuos regressions on
C++ code (like Gerald's testcase).  For C++ code we commonly produce
a=*(const char *)&char_vairable
like constructions produced by C++ casts.  RTL backend is able to use
subreg to do the cast in register, but for tree we can't.
Afaik Andrew and Richard has some plans to fix C++ forntend to do more
firendly casts, but I am not sure what is status of this task.
> 
> Another low-hanging candidate in this area is the extended basic block stuff
> of CSE.  -fno-cse-follow-jumps -fno-cse-skip-blocks (or whatever they're
> named) should give a first idea of the changes in SPEC numbers, but probably
> more can be gained by touching cse.c itself to remove unnecessary code and
> tests.

I did some SPEC testing and the regresisons were serious, tought I can't
dig out the numbers anymore unforutnately :(
> 
> Finally, in rest_of_handle_gcse, with -fexpensive-optimizations CSE is run
> repeatedly after GCSE until no jumps change.  Is this really helpful,
> especially with EBB CSE disabled?
> 
> I also have a patch to remove CONSTANT_P_RTX; performance tests made on
> mainline when purge_builtin_constant_p was introduced, showed that it took
> about 1% of bootstrap time.  However, purge_builtin_constant_p should actually
> be unused on the branch since builtin_constant_p is lowered well before the
> RTL expander.  There still may be a very small improvement (0.5% maybe),
> because it would simplify the CONSTANT_P predicate in rtl.h: a third of the 5%
> improvement gained by my RTX classes patch was due to simplifying CONSTANT_P.
> If you are interested in the patch I can polish it and send it on Monday or
> Tuesday.

I think elliminate of CONSTNT_P_RTX makes a lot of sense now.
> 
> IIRC, jump bypassing takes about 2% of compile time.  Actually when jump
> bypassing was introduced, it sped up bootstrap because GCC's enormous
> conditionals are well suited to jump bypassing; but now tree-ssa-dom should
> have made it almost obsolete on the branch, shouldn't it?  Again, SPEC testing
> is the only possible guidance.

Jeff has some numbers showing that RTL jump bypass pass makes very few
matches on GCC bootstrap.  I would think a lot in favour of removing it
or making it run just once instead of three times.

I can run the SPECs for these.

Honza
> 
> Hope this helps,
> 
> Paolo
> 
> 
> 

Re: [tree-ssa] Merge status

[Richard Guenther]

Gerald Pfeifer wrote:
> On Sat, 13 Mar 2004, Richard Guenther wrote:
> 
>>Yes, I suspect for a start we can move some optimizations from -O2 to
>>-O3 to improve -O2 compile time.
> 
> 
> Now, that's cheating, isn't it?  This is acceptable if and only if it
> really never hurts runtime performance, but then I don't see the benefit
> of such optimizations at all!

Of course it is cheating ;)  But there may be architectures that need a 
lot CSE/GCSE cleanup from their rtl patterns?  Also one could certainly 
find testcases where f.i. gcse does something useful, so entirely 
removing it is not going to happen soon - moving it to -O3 or even 
removing it from any -On might be prefferable.

F.i. I preffer -fpeel-loops over -funroll-loops to trigger complete 
peeling of constant times running loops - it's actually faster.  But 
-fpeel-loops and -funroll-loops are not enabled at any -On level.

With tree-ssa revisiting of -On enabled options is certainly necessary 
and possibly profitable.  Like maybe making -O default, not -O0 (usually 
-O0 compile times are worse than -O1 for me).

Richard.

Re: [tree-ssa] Merge status

[Gerald Pfeifer]

On Sat, 13 Mar 2004, Richard Guenther wrote:
> Yes, I suspect for a start we can move some optimizations from -O2 to
> -O3 to improve -O2 compile time.

Now, that's cheating, isn't it?  This is acceptable if and only if it
really never hurts runtime performance, but then I don't see the benefit
of such optimizations at all!

Gerald
-- 
Gerald Pfeifer (Jerry)   gerald@pfeifer.com   http://www.pfeifer.com/gerald/

Re: [tree-ssa] Merge status

[Richard Guenther]

Diego Novillo wrote:
> On Sat, 2004-03-13 at 10:40, Richard Guenther wrote:
> 
> 
>>Run time performance.  Compile time improved 5%.
>>
> 
> Excellent.  Thanks.

Yes, I suspect for a start we can move some optimizations from -O2 to 
-O3 to improve -O2 compile time.

Richard.

Re: [tree-ssa] Merge status

[Diego Novillo]

On Sat, 2004-03-13 at 10:40, Richard Guenther wrote:

> Run time performance.  Compile time improved 5%.
> 
Excellent.  Thanks.


Diego.

Re: [tree-ssa] Merge status

[Richard Guenther]

Diego Novillo wrote:
> On Sat, 2004-03-13 at 10:05, Richard Guenther wrote:
> 
> 
>>I once did experiments removing all gcse passes (-fno-gcse -fno-gcse-lm 
>>-fno-gcse-sm) and got no changes in resulting performance for the POOMA 
>>based applications.
>>
> 
> Compile or run time performance?

Run time performance.  Compile time improved 5%.

Richard.

Re: [tree-ssa] Merge status

[Diego Novillo]

On Sat, 2004-03-13 at 10:05, Richard Guenther wrote:

> I once did experiments removing all gcse passes (-fno-gcse -fno-gcse-lm 
> -fno-gcse-sm) and got no changes in resulting performance for the POOMA 
> based applications.
> 
Compile or run time performance?


Diego.

Re: [tree-ssa] Merge status

[Diego Novillo]

On Sat, 2004-03-13 at 09:55, Paolo Bonzini wrote:

> Are the performance problems on SPEC2000int (and the improvements in
> SPEC2000fp) concentrated in a single test?
> 
No.  If you look at the individual tests, perlbmk and crafty are the
more problematic 

http://people.redhat.com/dnovillo/spec2000/tree-ssa-branch/individual-run-ratio.html

Jeff Law and Andrew Macleod have both profiled SPEC in more detail and
had some ideas.


> Hope this helps,
> 
It does.  Thanks.


Diego.

Re: [tree-ssa] Merge status

[Richard Guenther]

Paolo Bonzini wrote:
>>For SPEC2000int, the branch is 2% behind mainline on x86.  For
>>SPEC2000fp, the branch is 0.4% ahead.  I will post x86-64 resuts soon.
> 
> 
> Are the performance problems on SPEC2000int (and the improvements in
> SPEC2000fp) concentrated in a single test?
> 
> 
>>Currently, bootstrap times on the branch are 14% slower than mainline
>>[...] Work is underway to remove some RTL passes

I once did experiments removing all gcse passes (-fno-gcse -fno-gcse-lm 
-fno-gcse-sm) and got no changes in resulting performance for the POOMA 
based applications.

Richard.

Re: [tree-ssa] Merge status

[Paolo Bonzini]

> For SPEC2000int, the branch is 2% behind mainline on x86.  For
> SPEC2000fp, the branch is 0.4% ahead.  I will post x86-64 resuts soon.

Are the performance problems on SPEC2000int (and the improvements in
SPEC2000fp) concentrated in a single test?

> Currently, bootstrap times on the branch are 14% slower than mainline
> [...] Work is underway to remove some RTL passes

It may be interesting to try without ADDRESSOF; I cannot test it fully but I
made some experiments; I simply tweaked function.c to not generate it, but Jan
has posted a polished patch which AFAIK is still waiting for review.  I
successfully bootstrapped mainline without all three of ADDRESSOF generation,
CSE1 (oh yeah) and the small purge_addressof pass.  This helps bootstrapping
time, but somebody should do SPEC tests to see if it causes performance
problems for the other merge criterion -- with Jan's patch, the necessary
modification is as easy as emptying rest_of_handle_cse and
rest_of_handle_addressof.

Another low-hanging candidate in this area is the extended basic block stuff
of CSE.  -fno-cse-follow-jumps -fno-cse-skip-blocks (or whatever they're
named) should give a first idea of the changes in SPEC numbers, but probably
more can be gained by touching cse.c itself to remove unnecessary code and
tests.

Finally, in rest_of_handle_gcse, with -fexpensive-optimizations CSE is run
repeatedly after GCSE until no jumps change.  Is this really helpful,
especially with EBB CSE disabled?

I also have a patch to remove CONSTANT_P_RTX; performance tests made on
mainline when purge_builtin_constant_p was introduced, showed that it took
about 1% of bootstrap time.  However, purge_builtin_constant_p should actually
be unused on the branch since builtin_constant_p is lowered well before the
RTL expander.  There still may be a very small improvement (0.5% maybe),
because it would simplify the CONSTANT_P predicate in rtl.h: a third of the 5%
improvement gained by my RTX classes patch was due to simplifying CONSTANT_P.
If you are interested in the patch I can polish it and send it on Monday or
Tuesday.

IIRC, jump bypassing takes about 2% of compile time.  Actually when jump
bypassing was introduced, it sped up bootstrap because GCC's enormous
conditionals are well suited to jump bypassing; but now tree-ssa-dom should
have made it almost obsolete on the branch, shouldn't it?  Again, SPEC testing
is the only possible guidance.

Hope this helps,

Paolo