Re: GCC Status (2004-08-09)

[Dorit Naishlos <DORIT at il dot ibm dot com>]

> So, for the time being, I'd like to focus on merging vectorization
> from the LNO branch to the mainline.  Dorit, would you please prepare
> a patch or patches, do appropriate testing, and post them for review,
> copying me?

Sure.

These are the planned vectorizer patches (not necessarily in this order):

(1) First major patch (infrastructure and basic functionality).
Submitted: http://gcc.gnu.org/ml/gcc-patches/2004-07/msg02127.html
This patch contains all the functionality from lno, except for
unknown-loop-bound support. I am in the process of addressing rth's
comments for this patch (thanks!).

(2) (Olga) Support for unknown loop bound (including loop peeling utility
for the vectorizer). Depends on patch (1).

(3) (Olga) Peeling to force the alignment of a data-reference in the loop.
Depends on patches (1),(2).

(4) Support misaligned loads. This involves porting functionality from
apple-ppc-branch, replacing builtins with new tree-codes (see proposal:
http://gcc.gnu.org/ml/gcc/2004-08/msg00317.html). Depends on patch (1), and
agreeing on tree-codes.

(5) (Devang) Support if-conversion and vectorization of conditional code.
This involves porting functionality from apple-ppc-branch, replacing
builtins with new tree-codes. Depends on patch (1), and agreeing on
tree-codes.

(6) Pattern recognition. This involves porting functionality from
apple-ppc-branch. Depends on (1).

(7) In the meantime there are things in the works on lno (e.g, support for
multidimensional arrays), for which we may try to send a patch for mainline
too.

thanks,

dorit.



|---------+------------------------------>
|         |           mitchell@mail.codes|
|         |           ourcery.com        |
|         |           Sent by:           |
|         |           gcc-owner@gcc.gnu.o|
|         |           rg                 |
|         |                              |
|         |                              |
|         |           09/08/2004 21:45   |
|---------+------------------------------>
  >---------------------------------------------------------------------------------------------------------------|
  |                                                                                                               |
  |       To:       gcc@gcc.gnu.org                                                                               |
  |       cc:       Dorit Naishlos/Haifa/IBM@IBMIL, dje@watson.ibm.com                                            |
  |       Subject:  GCC Status (2004-08-09)                                                                       |
  >---------------------------------------------------------------------------------------------------------------|





Several people have been making it abundantly clear that it's time for
me to update the world on plans for GCC 3.4.2 and GCC 3.5.  I have
been remiss.  To some extent, I've been waiting for the tree-ssa dust
to settle; until we were sure how that was going to come out it was
hard to see clearly what path to take to GCC 3.5.  And, on the other
hand, I've just been flaky.

Dorit, I've got a specific action item for you below, if you are
willing.

David, you too -- but maybe you can just help me coordinate with the
right people.

GCC 3.4.2
=========

The GCC 3.4.1 release was made July 1, which put the next release on
the schedule for September 1.  I think that date is completely
achievable.  There are 117 bugs targeted at GCC 3.4.2, but most of
them do not look terribly important, and I see none that are marked as
regressions from GCC 3.4.0.  In other words, I see no obstacles that
would prevent a user of GCC 3.4.1 from upgrading to GCC 3.4.2, which
is the key criteria for a bug-fix release.

However, a lot of the bugs open against GCC 3.4.2 are also GCC 3.5
regressions, and in that context they are more important.  Those bugs
might prevent people who are using GCC 3.3.x or previous from
upgrading to GCC 3.5.

GCC 3.5
=======

There are 127 bugs targeted at GCC 3.5.  That is in addition to the
117 bugs mentioned above, many of which apply to GCC 3.5 as well.  So,
conservatively, we have as many as 244 bugs targeted at GCC 3.5.  That
is not more than we have often had at this point in the process, but
it does make clear that we have our work cut out for us.  Historical
precedent suggests that tese bugs will not go away through random
bug-fixing; it will take a concerted effort by some of our leading
developers to go through and fix them.  These bugs include 25
wrong-code bugs; the category of bugs which have the most severe
impact on users.

In addition, it's not entirely clear how good the code generated from
GCC 3.5 is relative to the code generated from earlier releases.  I've
heard everything from "much better" to "much worse"; my current guess
is "not too different".  (We have a customer who has asked us to do a
more thorough investigation.)  That's part of why I've been reviewing
the LNO branch changes; my hope is that some of the improvements there
will help to improve the generated code.

It would be a disappointment to release 3.5 if we're getting inferior
benchmark numbers relative to 3.4.x.  I'm hoping that the numbers are
already better, or can relatively easily be made to be better.  Right
now, Diego's tester is showing us close to GCC 3.3.x on integer and
floating-point tests -- but well behind GCC 3.1.x and 3.2.x on
floating-point tests.  (Something untoward happened in late July it
looks like.)  I'm not too surprised by these results; our new
optimization infrastructure is groovy, but the RTL optimizers had been
tuned for a decade, so it will take a while to do substantially
better.

If, ultimately, we have to choose between releasing GCC 3.5 with
inferior performance and not releasing it at all, we will eventually
have to release it -- but let's try not to get ourselves into that
pickle.  I'd be interested in impressions from Diego, Jeff Law, RTH,
etc. on the current state of the optimizers.

As for LNO, things are getting a bit confusing for me.  The reason I'm
confused is that I don't know exactly what functionality is already on
the LNO branch, what functionality people are planning to add there,
and what functionality people feel is mature enough for mainline.  At
this point, I mentally divide LNO into two major categories: (1)
auto-vectorization, and (2) everything else.  I need a little more
specificity on (2); see below.

In any case, I'd like to start with (1).  The vectorizer is unlikely
to do any harm; the most frequent complaint I've heard is that it
doesn't vectorize enough loops.  And, vectorization -- even if
somewhat incomplete -- will be an exciting feature for GCC 3.5 that
will show what all the new optimization infrastructure can do.

So, for the time being, I'd like to focus on merging vectorization
from the LNO branch to the mainline.  Dorit, would you please prepare
a patch or patches, do appropriate testing, and post them for review,
copying me?

In the meanwhile, would someone (David Edelsohn?) please prepare a
list of other functionality on the LNO branch that seems appropriate
for GCC 3.5?  It would be good to know, for each set of changes, what
exactly it does and whether or not it has been shown to improve the
generated code.  We'll want to do some kind of topological sort and
merge these things in.  I'd like to have relative quiet on the LNO
branch while we do these things, if possible.

In terms of time frame, I'd like to go to Stage 3 on or about
September 5th.  If there are additional LNO changes that have a
positive impact on performance, we can consider them after that time.
The final GCC 3.5 release date will depend largely on the rate of bug
fixing, but early 2005 seems likely at this point.

--
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com