GCC 3.5 Plan, Take 2

[Andrew Pinski]

On Aug 15, 2004, at 6:47 PM, Mark Mitchell wrote:

> We're already better than GCC 3.4 on a lot of these axes.  Right now,
> we're probably losing a bit on compile-time, especially with
> optimization enabled, and most people seem to think code generation is
> about a wash.

I don't you can claim that compile time is slower with optimization 
enabled.
I will say that there is a bug report that was slow for all of GCC up 
till
tree-ssa.  See PR 2692 which says that the compile time for the tree-ssa
has improved many different things, there are other examples where 
expand
was taking a huge amount of time because inlining was happening before
expand and now we just actually do a many optimizations before expand 
making
expand less important.  What is even more impressive is that we added 
more
optimization passes and the overall compile time speed is about the same
as before the tree-ssa merge.

Most of the current compile time problems with the tree-ssa 
optimizations are
that they are O(n^2) see PR 15524 for an example of where one problem 
is, I and
Steven had hoped the rewrite of jump threading would improve the 
situation
here but it seems like we were wrong.

Also the reason behind the wash in code generation is because the tree 
optimizations
do not do much more than the current generation of RTL optimizers 
except for SRA which
is the single biggest win for more C++ programs.  The other big wins 
are DCE done right
and done before sib calling finding happens.

I also see that we can find uninitialized variables a lot better and 
IMA optimization
is done with the correct aliasing sets and ...

I can continue on what makes up this release so far, there are 244 bugs 
fixed for 3.5.0
which are not regressions and not fortran, and libjava (AWT and SWING 
also).

Oh, we also have a beginning implementation of AWT and SWING now for 
3.5.0 for libjava.

Every one in GCC keeps forgetting about the GCJ and other languages 
besides C and C++.

-- Pinski