Re: GCC 3.5 Status (2004-08-29)

[Steven Bosscher <stevenb at suse dot de>]

On Monday 30 August 2004 02:03, Mark Mitchell wrote:
> Steven Bosscher wrote:
> >On Monday 30 August 2004 01:17, Mark Mitchell wrote:
> >>The following changes will be postponed until GCC 3.6.  These changes
> >>either provide too little benefit, are too risky, or will take too
> >>much time to complete.
> >>
> >>* Aliasing improvements for structure fields [Berlin]
> >
> >But you should
> >realize that this analysis is absolutely critical if GCC 3.5 is going
> >to perform reasonably well.
>
> I am not convinced of this statement.
>
> First, the compiler speed argument mostly affects optimizing
> compilations, where compile-times are much less critical than
> non-optimizing compilations.  I'm sure that people will want to argue
> this point, but I've been talking with customers for a decade and the
> ones concerned about compile-times are almost always willing to have
> optimizing compilation take longer.

Hmm, let's argue.  So you think 25-100% slowdown is justifyable despite
just about every project using GCC complaining about how GCC gets slower
with each release?

Are you aware of the compile time comparisons from Diego?
http://people.redhat.com/dnovillo/spec2000/gcc/individual-build-secs_elapsed.html

As you can see, we are between 25 and 100% slower on almost _every_ SPEC
benchmark that compiled with older GCCs as well.  Only eon (C++) builds
faster, and ammp is about the same as GCC 3.4.
For most benchmarks we need 2.5 - 3 times as long as icc - which happens
to also outperform GCC on just about every benchmark.

People may be willing to accept a slower compiler when optimizing, but 
by now even I am wondering if I should just switch to a faster compiler
that also produces better code on this very popular target  ;-)


> Second, Dan said it will take 2-3 months to complete this work.  That's
> a lot of time, and indicates a big project.

Dan has so far been entirely on his own.  Note that his alias solver is
as good as ready, it just needs to be integrated in CC.  I don't know how
much work it would take, but apparently a lot.  Perhaps if more people
could help out (which is actually already happening), this doesn't have
to take 3 months.  Dan/Diego/RTH can probably come up with more comments
on this.


>  I am confident that there
> are alternatives that, while perhaps less comprehensive, get enough of
> the common cases to achieve most of the benefits.

What is your confidence based on?  What common cases?  Did Dan tell you
about the issues that he's fighting?  No "less comprehensive" solution
exists that will not run into the exact same problems.


> Third, if this change is so vital, then we should be willing to drop
> some other changes in favor of this one, so that people can work with
> Dan to finish this one.  Why don't you suggest some changes that are
> already on the list that you'd be willing to give up?

The things I currently work on that I would drop right away:
* Edges-in-vectors conversion [Elliston]
* Tree-based profile-directed feedback [Hubicka]

Things that I think are not as important as beter AA:
* Linear loop transforms [Berlin]
* Variable expansion optimization [Eres]
* Tree-based branch prediction [Hubicka]
...and probably other stuff, but these are the only ones from which I
think we reasonably expect that they would help Dan (hey, is he on that
list?!) with his AA work.

Gr.
Steven