[RFC] Contributing tree-ssa to mainline

[RFC] Contributing tree-ssa to mainline

[Diego Novillo]

Now that we are about to enter Stage 1 of 3.5, I wanted to solicit
feedback regarding the merge of the tree-ssa branch into mainline.

First and foremost is the obvious question of whether people think that
the whole infrastructure is worth adding to GCC at all.  From what we've
discussed in the past few months, the consensus seems to be that it is. 
But I think it's important to find out if folks think otherwise.

If we decide to add SSA for 3.5, then we need to determine exactly how
we are going to go about it.  I will try to summarize the more important
points to get the discussion going.  In the following I assume that we
have decided to add tree-ssa to GCC:


1- The changes in tree-ssa are pretty big.  A quick diff against the 3.4
branchpoint in the gcc directory shows

 11558 files changed, 161996 insertions(+), 14697 deletions(-), 30494 modifications(!)

Some of that is due to the drift since the latest merge, but that should
give you an idea.  That doesn't include changes to ../lib*.


2- Ada and g77 do not work anymore.  The new Fortran 95 front end
replaces g77, though I'm not sure what's the compatibility situation. 
There is no replacement for Ada.  As it is today, it is impossible to
build an Ada compiler with the branch.


3- There are several bug reports opened against the branch (92 as of
today).


4- The branch lags in performance wrt mainline by about 3% in SPECint
and is about 4% faster in SPECfp (take these numbers with a grain of
salt, this is from my daily SPEC runs).


So, there clearly is much work to be done yet.  A very conservative view
would be to declare the branch still not ripe for inclusion and wait for
GCC 3.6.

Pros	Mainline is not disrupted with such major changes.
	We avoid a possibly lengthy 3.5 cycle.
	Other major work can go in without worrying about the new
	infrastructure.

Cons	The SSA bits stay secluded without the benefits of the
	widespread testing done on mainline.
	Other major changes may interfere with tree-ssa, slowing down
	progress in the branch.
	Benefits given by the new infrastructure cannot be used for new
 	work.


Another thing to consider is that we need to have peer review for all
the changes done in the branch.  The implementation and/or design will
need to be reviewed and may require extensive changes.

If we are going to merge during Stage1, we could either phase in all the
changes separately or just drop the whole thing at once.  For reviewing
purposes, we probably want to phase-in.  Though, we could do the review
separately and then drop the whole thing.  The are few independent
chunks in the branch (listed in precedence order):

     1. Folder changes.
     2. GENERIC/GIMPLE.
     3. tree->rtl expanders.
     4. g95.
     5. SSA infrastructure
             A. operand discovery.
             B. alias analysis.
             C. pass manager.
             D. individual passes.

2 and 3 need to go in together and are the ones that prevent Ada and g77
from working.  So, once those are in, we can't go back.

I may be forgetting a bunch of stuff.  I would like to reach a consensus
soonish so that we can plan accordingly.


Thanks.  Diego.

Re: [RFC] Contributing tree-ssa to mainline

[Daniel Berlin]

>              D. individual passes.
>

I seriously think re-reviewing each part of tree-ssa as it is merged to 
the mainline is a bad idea.

Their were specific design choices made, and discussed on the mailing 
list, during design and implementation of tree-ssa over the years.

All the passes were reviewed as they were added, and implemented by 
many of the same people who would be reviewing them now.

The only possible thing that reviewing them again could cause is a 
rehash of the same design issues and tradeoffs that were made in the 
first place.

I strongly believe it should be merged in one piece.

Piecemeal merging will also cause nothing but troubles where we've 
forgotten some small piece of something that was in another file, etc.

It also will significantly affect the performance numbers you have 
posted, since some passes depend on other passes to cleanup their 
garbage and avoid doing certain things we know have already been 
done(For example, PRE doesn't do what the dominator optimizers do, on 
purpose).  So you'd have to get them in in the right order anyway, or 
else someone might see the fact that it doesn't handle something as a 
"flaw" instead of a design decision.

--Dan

Re: [RFC] Contributing tree-ssa to mainline

[Andrew Pinski]

On Jan 16, 2004, at 16:19, Diego Novillo wrote:

> 3- There are several bug reports opened against the branch (92 as of
> today).

There are really only 90 bugs (2 were reported against the tree-ssa but 
also effect the
mainline also).


Also out of those 90 bugs, 19 are suspended because they are fixed on 
the tree-ssa.
Also two of these 90 are bugs which will be fixed with a merge from the 
mainline (or
the other way around).
15 bugs are enhancement.

There are 54 bugs which are not fixed on the tree-ssa and effect only 
the tree-ssa.

Out of those 54 bugs, 28 are bugs against gfortran (and its support 
library).

So that leaves only 26 bugs which effect the optimization parts of the 
compiler (mostly ICEs
and wrong-code).


Thanks,
Andrew Pinski

Re: [RFC] Contributing tree-ssa to mainline

[Gerald Pfeifer]

On Fri, 16 Jan 2004, Diego Novillo wrote:
> First and foremost is the obvious question of whether people think that
> the whole infrastructure is worth adding to GCC at all.  From what we've
> discussed in the past few months, the consensus seems to be that it is. 

Given the number and qualification of those working on tree-ssa
(including many volunteers and full-time GCC hackers from at least
two companies with major interest and contributions to GCC) I think
the answer is "Yes". :-)

> As it is today, it is impossible to build an Ada compiler with the
> branch.

I'm afraid that's a blocker.

> 3- There are several bug reports opened against the branch (92 as of
> today).

I believe the general policy, not specific to tree-ssa, is that everything
that is a regression of a branch compared to mainline blocks the merger of
that branch.

(This is the direct analogon to our patch rules, where a patch with
known regressions must not be applied. In fact, merging a branch is
a large patch.)

> So, there clearly is much work to be done yet.  A very conservative view
> would be to declare the branch still not ripe for inclusion and wait for
> GCC 3.6.

Well, it may not be ripe now (and in fact I'm currently suffering from
code generation bugs on tree-ssa), but how about four, or six, or eight
weeks?

From my personal point of view, tree-ssa nearly seems be there, in terms
of quality.

Gerald

Re: [RFC] Contributing tree-ssa to mainline

[law]

In message <Pine.LNX.4.58.0401170133440.4464@D209.suse.de>, Gerald Pfeifer writ
es:
 >On Fri, 16 Jan 2004, Diego Novillo wrote:
 >> First and foremost is the obvious question of whether people think that
 >> the whole infrastructure is worth adding to GCC at all.  From what we've
 >> discussed in the past few months, the consensus seems to be that it is. 
 >
 >Given the number and qualification of those working on tree-ssa
 >(including many volunteers and full-time GCC hackers from at least
 >two companies with major interest and contributions to GCC) I think
 >the answer is "Yes". :-)
 >
 >> As it is today, it is impossible to build an Ada compiler with the
 >> branch.
 >
 >I'm afraid that's a blocker.
It could mean we disable Ada until such time as it's brought into the
modern world by its maintainers.  IIRC we're still waiting on Ada to
support function at a time mode.

jeff

Re: [RFC] Contributing tree-ssa to mainline

[law]

In message <Pine.LNX.4.58.0401170133440.4464@D209.suse.de>, Gerald Pfeifer writ
es:
 >Well, it may not be ripe now (and in fact I'm currently suffering from
 >code generation bugs on tree-ssa), but how about four, or six, or eight
 >weeks?
BTW, you might try with my out-of-ssa bugfixes from yesterday.  While
I hadn't run into those bugs in the wild, you might have been tripping
over them...

jeff

Re: [RFC] Contributing tree-ssa to mainline

[Eric Christopher]

> 
> I'm afraid that's a blocker.

On whom though? If it is decided that tree-ssa is the way to go by the
group at large whose responsibility is it? The other language
maintainers have converted their own bits - is it up to ACT (since no
one else works on ADA afaict) to convert or do the tree-ssa people have
to do the conversion - after all that has already been done?

If ACT decides they don't have time to do this - then is it still a
blocker?

-eric

-- 
Eric Christopher <echristo@redhat.com>

Re: [RFC] Contributing tree-ssa to mainline

[Joseph S. Myers]

On Sat, 17 Jan 2004, Gerald Pfeifer wrote:

> > 3- There are several bug reports opened against the branch (92 as of
> > today).
> 
> I believe the general policy, not specific to tree-ssa, is that everything
> that is a regression of a branch compared to mainline blocks the merger of
> that branch.
> 
> (This is the direct analogon to our patch rules, where a patch with
> known regressions must not be applied. In fact, merging a branch is
> a large patch.)

And the branch merger has the additional requirements of no regressions in
the testsuite on three different CPU targets.  For this major change I
think testing with no regressions on all primary release platforms (as in
the 3.3 release criteria if no later version is available, but allowing
later versions of the operating systems since many of those listed are
obsolete, and e.g. variation in the particular GNU/Linux distributions
used with a given target triplet) would be appropriate - that covers six
CPUs.

How does compile-time performance compare to mainline?

I take it you believe that all the coding conventions are properly
followed on tree-ssa?  For example, all command-line options added are
documented, including the details of what is enabled at what -O levels
(listed both under the options themselves and under the -O options); the
documentation of trees is up to date and covers everything new about them;  
sourcebuild.texi appropriately covers the gfortran library and the
tree-ssa testsuites; passes.texi gives an accurate description of how the
compiler now operates, documenting the tree-ssa source files
appropriately; no files have copyright notices referencing "GNU CC".

-- 
Joseph S. Myers
jsm@polyomino.org.uk

Re: [RFC] Contributing tree-ssa to mainline

[Gerald Pfeifer]

On Fri, 16 Jan 2004 law@redhat.com wrote:
> BTW, you might try with my out-of-ssa bugfixes from yesterday.  While
> I hadn't run into those bugs in the wild, you might have been tripping
> over them...

Yes.  The original problems I had went away a few days ago, but I'm
seeing other (apparent) code gen bugs now. :-(

I'm trying to investigate...

Gerald

Re: [RFC] Contributing tree-ssa to mainline

[Diego Novillo]

On Fri, 2004-01-16 at 20:37, Gerald Pfeifer wrote:
> On Fri, 16 Jan 2004 law@redhat.com wrote:
> > BTW, you might try with my out-of-ssa bugfixes from yesterday.  While
> > I hadn't run into those bugs in the wild, you might have been tripping
> > over them...
> 
> Yes.  The original problems I had went away a few days ago, but I'm
> seeing other (apparent) code gen bugs now. :-(
>
We have been having bootstrap problems on ia64 that started showing up
between 2004-01-08 and 2004-01-15.  The tester had stopped sending me
daily mail and I didn't notice until today when I saw PR 13709.  Dunno
if they're related.


Diego.

Re: [RFC] Contributing tree-ssa to mainline

[Kaveh R. Ghazi]

 > > > 3- There are several bug reports opened against the branch (92 as
 > > > of today).
 > > 
 > > I believe the general policy, not specific to tree-ssa, is that
 > > everything that is a regression of a branch compared to mainline
 > > blocks the merger of that branch.
 > > 
 > > (This is the direct analogon to our patch rules, where a patch with
 > > known regressions must not be applied. In fact, merging a branch is
 > > a large patch.)
 > 
 > And the branch merger has the additional requirements of no
 > regressions in the testsuite on three different CPU targets.  For this
 > major change I think testing with no regressions on all primary
 > release platforms (as in the 3.3 release criteria if no later version
 > is available, but allowing later versions of the operating systems
 > since many of those listed are obsolete, and e.g. variation in the
 > particular GNU/Linux distributions used with a given target triplet)
 > would be appropriate - that covers six CPUs.
 > 
 > How does compile-time performance compare to mainline?
 > 
 > I take it you believe that all the coding conventions are properly
 > followed on tree-ssa?  For example, all command-line options added are
 > documented, including the details of what is enabled at what -O levels
 > (listed both under the options themselves and under the -O options);
 > the documentation of trees is up to date and covers everything new
 > about them; sourcebuild.texi appropriately covers the gfortran library
 > and the tree-ssa testsuites; passes.texi gives an accurate description
 > of how the compiler now operates, documenting the tree-ssa source
 > files appropriately; no files have copyright notices referencing "GNU
 > CC".

I would echo Gerald and Joseph's comments about regressions and
documentation.  (However IMHO, it's up to frontend maintainers to
upgrade their bits, so Ada and g77 not working is okay with me.)  I
also think it's fair to accept the work with some regressions as long
as we receive assurances that they'll be addressed full time and
quickly, like Mark has been doing with the new c++ parser.


But something is missing from Diego's call for discussion.  I think we
should at least expect a more thorough status report (beyond the SPEC
numbers which appear to be a wash.)  This should include tree-ssa's
original goals and how close we are to meeting them.

Over the last year in the mailing lists and in presentations at the
conference last May, my understanding was that tree-ssa promised many
good benefits, including:

1.  Better codegen from new and improved optimizations, some easier or
    only possible in an SSA framework.

2.  Deletions of major gnarly old parts of GCC which would make
    maintenance easier.

3.  Deletions of superceded RTL optimization passes which would make
    GCC faster.

4.  New languages (i.e. g95, or whatever we're calling it now.)  What
    works and what's left?

(If I've missed any suggested benefits, please add them.)


Now I know when a radical project is in it's infancy, from an advocacy
perspective, it was in your interest a year ago to promise tree-ssa
would create world peace, cure cancer, etc.  And it's quite possible
we'll only meet some of these goals only partially and yet still feel
it's worthwhile to accept the work.  But I think it fair that you
describe where we're at and whether all of these are realistic or not.
Or maybe you've discovered you were too conservative and the promise
of the branch is even greater than originally described.  Either way,
we need this information.

		Thanks,
		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: [RFC] Contributing tree-ssa to mainline

[Gabriel Dos Reis]

"Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> writes:

| I would echo Gerald and Joseph's comments about regressions and
| documentation.  (However IMHO, it's up to frontend maintainers to
| upgrade their bits, so Ada and g77 not working is okay with me.)  I

I don't understand that argument.  

If someone contributes a patch that suddenly makes a front-end
non-working, we consider that a non-starter and reject the patch
until it addresses the "non-working" bits.  I do not consider it fair
to change the mainline in a disruptive way for x front-ends and says
it is x front-ends maintainers' business to make it work. 

[...]

| it's worthwhile to accept the work.  But I think it fair that you
| describe where we're at and whether all of these are realistic or not.

Agreed.

--Ggaby

Re: [RFC] Contributing tree-ssa to mainline

[Steven Bosscher]

On Saturday 17 January 2004 01:44, Gerald Pfeifer wrote:
> On Fri, 16 Jan 2004, Diego Novillo wrote:
> > First and foremost is the obvious question of whether people think that
> > the whole infrastructure is worth adding to GCC at all.  From what we've
> > discussed in the past few months, the consensus seems to be that it is.
>
> Given the number and qualification of those working on tree-ssa
> (including many volunteers and full-time GCC hackers from at least
> two companies with major interest and contributions to GCC) I think
> the answer is "Yes". :-)
>
> > As it is today, it is impossible to build an Ada compiler with the
> > branch.
>
> I'm afraid that's a blocker.

There's very little anyone can do about this until ACT decides
it is time to implement function-at-a-time.

Therefore I don't think it's a blocker.

Gr.
Steven

Re: [RFC] Contributing tree-ssa to mainline

[Kaveh R. Ghazi]

 > From: Gabriel Dos Reis <gdr@integrable-solutions.net>
 > 
 > "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> writes:
 > 
 > | I would echo Gerald and Joseph's comments about regressions and
 > | documentation.  (However IMHO, it's up to frontend maintainers to
 > | upgrade their bits, so Ada and g77 not working is okay with me.)  I
 > 
 > I don't understand that argument.  
 > 
 > If someone contributes a patch that suddenly makes a front-end
 > non-working, we consider that a non-starter and reject the patch
 > until it addresses the "non-working" bits.  I do not consider it fair
 > to change the mainline in a disruptive way for x front-ends and says
 > it is x front-ends maintainers' business to make it work. 

My feeling on this matter is purely in the context of all those
goodies promised.  If the new infrastructure is really that good, and
we all agree this is the "future" of GCC, I can live with some
frontends not working and asking it's community to pitch in and
upgrade it.

Feel free to disagree with me.  But remember, they (tree-ssa
advocates) promised a lot.  If it turns out to be just a different
infrastructure, as opposed to a better one, I wouldn't feel the same.

		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: [RFC] Contributing tree-ssa to mainline

[Steven Bosscher]

On Saturday 17 January 2004 02:55, Gabriel Dos Reis wrote:
> "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> writes:
> | I would echo Gerald and Joseph's comments about regressions and
> | documentation.  (However IMHO, it's up to frontend maintainers to
> | upgrade their bits, so Ada and g77 not working is okay with me.)  I
>
> I don't understand that argument.
>
> If someone contributes a patch that suddenly makes a front-end
> non-working, we consider that a non-starter and reject the patch
> until it addresses the "non-working" bits.  I do not consider it fair
> to change the mainline in a disruptive way for x front-ends and says
> it is x front-ends maintainers' business to make it work.

I would agree with you on principle.  But nobody is willing/able to
update g77, and for Ada, everyone knows Kenner has done some work in
this area but it's just not there and hasn't been for four years. So
do you think we should wait until someone cares enough to make this
transition?

Gr.
Steven

Re: [RFC] Contributing tree-ssa to mainline

[Robert Dewar]

Eric Christopher wrote:

> On whom though? If it is decided that tree-ssa is the way to go by the
> group at large whose responsibility is it? The other language
> maintainers have converted their own bits - is it up to ACT (since no
> one else works on ADA afaict) to convert or do the tree-ssa people have
> to do the conversion - after all that has already been done?

Certainly it is our intention to do this conversion

> If ACT decides they don't have time to do this - then is it still a
> blocker?

It's not a matter of not having time, but rather when the time can be
found, and when this work can be completed. That is indeed a problem
since this is quite a bit of work, and there are many other things
competing for time. As with any company, AdaCore's priorities are set
by its customers.

Re: [RFC] Contributing tree-ssa to mainline

[Daniel Berlin]

On Jan 16, 2004, at 9:17 PM, Kaveh R. Ghazi wrote:

>> From: Gabriel Dos Reis <gdr@integrable-solutions.net>
>>
>> "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> writes:
>>
>> | I would echo Gerald and Joseph's comments about regressions and
>> | documentation.  (However IMHO, it's up to frontend maintainers to
>> | upgrade their bits, so Ada and g77 not working is okay with me.)  I
>>
>> I don't understand that argument.
>>
>> If someone contributes a patch that suddenly makes a front-end
>> non-working, we consider that a non-starter and reject the patch
>> until it addresses the "non-working" bits.  I do not consider it fair
>> to change the mainline in a disruptive way for x front-ends and says
>> it is x front-ends maintainers' business to make it work.
>
> My feeling on this matter is purely in the context of all those
> goodies promised.  If the new infrastructure is really that good, and
> we all agree this is the "future" of GCC, I can live with some
> frontends not working and asking it's community to pitch in and
> upgrade it.
>
> Feel free to disagree with me.  But remember, they (tree-ssa
> advocates) promised a lot.

Most of which has been delivered, or at least, is in the process of 
being delivered:
"
1.  Better codegen from new and improved optimizations, some easier or
     only possible in an SSA framework.
"

Definitely true, as shown by things like SRA.


"2.  Deletions of major gnarly old parts of GCC which would make
     maintenance easier.
"
Various parts of the C expanders (which weren't pretty) have been 
deleted, and other code is starting to be deleted or significantly 
reworked to be much simpler.
One of the goals was to enable this to occur  This goal has *certainly* 
been successful. The goal of actually doing it is in process, of 
course.



>  If it turns out to be just a different
> infrastructure, as opposed to a better one, I wouldn't feel the same.
It is a better infrastructure.
A much better one.
I'll leave it to Diego and others to post performance numbers besides 
SPEC (though i'm happy to do so if necessary).

Re: [RFC] Contributing tree-ssa to mainline

[Robert Dewar]

Steven Bosscher wrote:

> There's very little anyone can do about this until ACT decides
> it is time to implement function-at-a-time.

Well of course there is no law that only AdaCore can do this work,
but in practice that does seem likely to be the case.

> Therefore I don't think it's a blocker.

I would agree with this ...

Re: [RFC] Contributing tree-ssa to mainline

[Robert Dewar]

Steven Bosscher wrote:

> I would agree with you on principle.  But nobody is willing/able to
> update g77, and for Ada, everyone knows Kenner has done some work in
> this area but it's just not there and hasn't been for four years. So
> do you think we should wait until someone cares enough to make this
> transition?

g77 seems a real problem to me. But of course anyone interested in
Ada or Fortran can perfectly well make a branch if they want.

Re: [RFC] Contributing tree-ssa to mainline

[Diego Novillo]

On Fri, 2004-01-16 at 20:51, Kaveh R. Ghazi wrote:


> But something is missing from Diego's call for discussion.  I think we
> should at least expect a more thorough status report (beyond the SPEC
> numbers which appear to be a wash.)  This should include tree-ssa's
> original goals and how close we are to meeting them.
> 
Very good point.  Thanks for bringing it up.  My original goal when I
started the project was very simple: modernize GCC's optimization
infrastructure.  To me that meant SSA, mostly because that's what I
brought with me from my University years.

Over the years GCC has done very well considering the ad-hoc nature of
most of its algorithms.  I mostly wanted for someone with knowledge
about optimizers in general and no knowledge of GCC, to be able to find
its way without much trouble.

> 1.  Better codegen from new and improved optimizations, some easier or
>     only possible in an SSA framework.
> 
The one example that, not surprisingly, comes to mind right now is SRA
(scalar replacement of aggregates).  It allows some optimizations that
apparently C++ users have been asking for a long time.  It eliminates
the need to commit structures to memory too early.  See PR12747 for
details.

The infrastructure also allows vectorizing transformations such as the
ones being planned for the LNO sub-branch.  That is still in an early
stage of development, so if the requirement is to have that in place
before merging, then we should just have this talk some other time.

We are close to the point where we can start disabling some parts of RTL
passes, which should provide compile-time improvements without run-time
regressions.  Jeff Law and Andrew Macleod have been working on that.

My original goal has almost been achieved.  We now have an
infrastructure in place that has many of the features needed to
implement global optimizers:

      * A well-defined language-independent IR (GIMPLE)
      * CFG and an API for manipulating it.
      * Type-based and points-to alias analysis.
      * An SSA form and related functionality to do data-flow analysis.
      * A pass manager to allow plugging in new transformations at will.


> 2.  Deletions of major gnarly old parts of GCC which would make
>     maintenance easier.
> 
This is in progress.  Though some progress has been made, particularly
in the areas of interfacing front ends with the optimizers.  In the
branch we have single points of contact between parsers and the
optimizer proper, for instance.

> 3.  Deletions of superceded RTL optimization passes which would make
>     GCC faster.
> 
Again, in progress.  I should add that even though we haven't yet
removed RTL passes, things like bootstrap times are only 2% slower on
the branch.  More work is needed in this area and in reducing memory
consumption.  This could be considered a blocker.


> 4.  New languages (i.e. g95, or whatever we're calling it now.)  What
>     works and what's left?
> 
I will defer to Toon Moene, Steven Bosscher or Paul Brook to answer this
one.

> (If I've missed any suggested benefits, please add them.)
> 
> 
> Now I know when a radical project is in it's infancy, from an advocacy
> perspective, it was in your interest a year ago to promise tree-ssa
> would create world peace, cure cancer, etc.
>
No.  Not my style.  Since my initial posting in Feb'01 I've always
wanted only one thing: modernize GCC's optimization infrastructure.

> Or maybe you've discovered you were too conservative and the promise
> of the branch is even greater than originally described.  Either way,
> we need this information.
> 
No.  In my mind, this was never a research project.  After all, we are
only teaching GCC to do the things that compiler books have been telling
us for more than 15 years.


Diego.

Re: [RFC] Contributing tree-ssa to mainline

[Andrew Pinski]

On Jan 16, 2004, at 19:02, Robert Dewar wrote:

> Steven Bosscher wrote:
>
>> I would agree with you on principle.  But nobody is willing/able to
>> update g77, and for Ada, everyone knows Kenner has done some work in
>> this area but it's just not there and hasn't been for four years. So
>> do you think we should wait until someone cares enough to make this
>> transition?
>
> g77 seems a real problem to me. But of course anyone interested in
> Ada or Fortran can perfectly well make a branch if they want.

Why would g77 be a big problem when gfortran (aka g95) exists?
gfortran should (or rather will in some cases) run f77 code.



Thanks,
Andrew Pinski
bug master

Re: [RFC] Contributing tree-ssa to mainline

[Diego Novillo]

On Fri, 2004-01-16 at 20:02, Joseph S. Myers wrote:

> How does compile-time performance compare to mainline?
> 
Bootstrap times are ~2% slower than mainline.  In the daily SPEC runs,
you will notice a mix.  Most of the time the branch is faster than
mainline.

http://people.redhat.com/dnovillo/spec2000/tree-ssa-branch/individual-build-secs_elapsed.html


> I take it you believe that all the coding conventions are properly
> followed on tree-ssa?  For example, all command-line options added are
> documented, including the details of what is enabled at what -O levels
> (listed both under the options themselves and under the -O options);
>
Yes.

>  the documentation of trees is up to date and covers everything new about them;
>
No.

> sourcebuild.texi appropriately covers the gfortran library and the
> tree-ssa testsuites;
>
Dunno re. gfortran.  Definite no for the testsuites.

>  passes.texi gives an accurate description of how the
> compiler now operates, documenting the tree-ssa source files
> appropriately;
>
No.

>  no files have copyright notices referencing "GNU CC".
>
Yes.


Thanks.  Are these requirements listed somewhere in our web pages? 
They'll be a useful reminder if we decide to merge the branch for 3.5.


Diego.

Re: [RFC] Contributing tree-ssa to mainline

[law]

In message <1074313953.5368.4.camel@frodo.toronto.redhat.com>, Diego Novillo wr
ites:
 >On Fri, 2004-01-16 at 20:02, Joseph S. Myers wrote:
 >
 >> How does compile-time performance compare to mainline?
 >> 
 >Bootstrap times are ~2% slower than mainline.  In the daily SPEC runs,
 >you will notice a mix.  Most of the time the branch is faster than
 >mainline.
 >
 >http://people.redhat.com/dnovillo/spec2000/tree-ssa-branch/individual-build-s
 >ecs_elapsed.html
 >
 >
 >> I take it you believe that all the coding conventions are properly
 >> followed on tree-ssa?  For example, all command-line options added are
 >> documented, including the details of what is enabled at what -O levels
 >> (listed both under the options themselves and under the -O options);
 >>
 >Yes.
Err, no they aren't.  For example we have a host of -f options which control
debugging dumps rather than code generation.  That's wrong.


Jeff

Re: [RFC] Contributing tree-ssa to mainline

[Andrew Pinski]

On Jan 16, 2004, at 22:13, law@redhat.com wrote:

> Err, no they aren't.  For example we have a host of -f options which 
> control
> debugging dumps rather than code generation.  That's wrong.


But so does C++ already, it has a couple of -fdump-* switches already.

-fdump-unnumbered does not effect code gen.
-fverbose-asm does not effect code gen either.
-fstats (C++) does not effect code gen either.
-ftime-report, -fmem-report.

I could go on, why has no one changed them if they are wrong?

Thanks,
Andrew Pinski

Re: [RFC] Contributing tree-ssa to mainline

[Diego Novillo]

On Sat, 2004-01-17 at 01:13, law@redhat.com wrote:

>  >> I take it you believe that all the coding conventions are properly
>  >> followed on tree-ssa?  For example, all command-line options added are
>  >> documented, including the details of what is enabled at what -O levels
>  >> (listed both under the options themselves and under the -O options);
>  >>
>  >Yes.
> Err, no they aren't.  For example we have a host of -f options which control
> debugging dumps rather than code generation.  That's wrong.
> 
So does mainline and all the releases that have included -fdump-tree... 
We didn't invent that.


Diego.

Re: [RFC] Contributing tree-ssa to mainline

[Andrew Walrond]

As a passive observer on this mailing list, I would feel a lot happier about 
SSA going into 3.5 if I didn't still have the bad taste from the "Lets chuck 
3.4 out the door, warts an all, as fast as possible" thread which got 
everybody so worked up recently.

I really like the sound of SSA going into 3.5, but it surely makes 3.4 a much 
more important release with the emphasis on quaility rather than haste, 
because we users ar going to depend on it for much longer, even beyond a 3.5 
release if ada/g77 will be missing.

Andrew Walrond

Re: [RFC] Contributing tree-ssa to mainline

[Joseph S. Myers]

On Sat, 17 Jan 2004, Diego Novillo wrote:

> Thanks.  Are these requirements listed somewhere in our web pages? 
> They'll be a useful reminder if we decide to merge the branch for 3.5.

codingconventions.html has all the documentedness requirements.  Such
things as no "GNU CC" references are a matter of having followed all the
global cleanups that have gone in on mainline while tree-ssa has been on a
branch, and done them on tree-ssa to the extent that CVS merges wouldn't
have caught them.

One key advantage of tree-ssa (as I see it) is a cleaned-up front-end
interface.  As such it is a golden opportunity for a *documented*
front-end interface, so I think it is critical that everything new and
changed in the front-end interface must be documented when the branch is
merged if we are ever to aspire to having the front-end interface even as
well documented as the back-end interface (which still suffers from
maintainers adding undocumented interfaces and ignoring regression bugs
such as 3386).

-- 
Joseph S. Myers
jsm@polyomino.org.uk

Re: [RFC] Contributing tree-ssa to mainline

[Giovanni Bajo]

Diego Novillo wrote:

> We are close to the point where we can start disabling some parts of
> RTL passes, which should provide compile-time improvements without
> run-time regressions.  Jeff Law and Andrew Macleod have been working
> on that.

I think this is a very important point. When you succeed showing that tree-ssa
can actually *replace* entire (or big parts of) RTL optimizers, it would be
clear that it's a big win per-se, even if it were not improving SPEC points or
C++ testcases (which is in fact doing).

On the other hand, is there an alternative mission for 3.5? Are there other big
changes which were waiting for Stage 1 to be merged? If we are going to just
bugfix 3.4 and maybe add a couple of new targets, we can as well merge tree-ssa
this morning.

Giovanni Bajo

Re: [RFC] Contributing tree-ssa to mainline

[Jan Hubicka]

> > 3.  Deletions of superceded RTL optimization passes which would make
> >     GCC faster.
> > 
> Again, in progress.  I should add that even though we haven't yet
> removed RTL passes, things like bootstrap times are only 2% slower on
> the branch.  More work is needed in this area and in reducing memory
> consumption.  This could be considered a blocker.

We already elliminated tailcall pass.

I have patches to kill ADDRESSOF scheme and it only waits for the patch
concerning aliasing of arrays to be rewieved.

Zdenek has patch to elliminate loop header duplication that is AFAIK
also just waiting for approval.

Loop optimizer is being worked on.

There are other easy targets - NULL pointer ellimination for instance
that I was discussing with Jeff.

With the RTL expansion patch and loop optimizer we can elliminate need
for RTL branch prediction and profiling passes, tought I want to keep
the second in the tree to allow sanity checking of profile updating code
as discused earlier.

So even tought we won't easilly elliminate CSE, GCSE and one of 3 passes
of jump threading, many of other cases are already here.

I would also like to kill RTL BUILTIN_CONSTANT_P construct RSN.

Honza

Re: [RFC] Contributing tree-ssa to mainline

[Scott Robert Ladd]

Diego Novillo wrote:
> Now that we are about to enter Stage 1 of 3.5, I wanted to solicit
> feedback regarding the merge of the tree-ssa branch into mainline.

Thank you for raising this topic!

> First and foremost is the obvious question of whether people think that
> the whole infrastructure is worth adding to GCC at all.  From what we've
> discussed in the past few months, the consensus seems to be that it is. 
> But I think it's important to find out if folks think otherwise.

I would like to see tree-ssa become mainline as soon as possible. I see
no point in putting major work into gfortran and gomp if that effort is
going to continue to be speculative, nor do I see an easy way to
implement those features (Fortran 95 and OpenMP) in the current mainline.
> 1- The changes in tree-ssa are pretty big.  A quick diff against the 3.4
> branchpoint in the gcc directory shows
> 
>  11558 files changed, 161996 insertions(+), 14697 deletions(-), 30494 modifications(!)

The problem only grows worse with time. It's time to fish or cut bait.

> 2- Ada and g77 do not work anymore.  The new Fortran 95 front end
> replaces g77, though I'm not sure what's the compatibility situation. 
> There is no replacement for Ada.  As it is today, it is impossible to
> build an Ada compiler with the branch.

The Ada issue is an important one, I think. I don;t know the issues very
well; has anyone even considered how the existing Ada compiler might be
integrated into SSA?

> 3- There are several bug reports opened against the branch (92 as of
> today).

All branches have bugs. Put SSA in mainline, and we might find more
people to work on them.

> 4- The branch lags in performance wrt mainline by about 3% in SPECint
> and is about 4% faster in SPECfp (take these numbers with a grain of
> salt, this is from my daily SPEC runs).

I'll try to put together some numbers this weekend based on my
independent test suites.

> So, there clearly is much work to be done yet.  A very conservative view
> would be to declare the branch still not ripe for inclusion and wait for
> GCC 3.6.

As far as I can see, delay gains us nothing but delay. What, precisely,
would go into a non-SSA 3.5, beyond bug fixes? Waiting for 3.6 would
only increase the difficulty of moving SSA to mainline due to increased
"drift".

> Pros	Mainline is not disrupted with such major changes.
> 	We avoid a possibly lengthy 3.5 cycle.
> 	Other major work can go in without worrying about the new
> 	infrastructure.

Other Pros:

We would have a working Fortran 95 compiler.

OpenMP would get more attention, and might actually see the light of day.

I've spoken to some people who might contribute to OpenMP, but who think
tree-ssa is too tentative to risk wasting effort.

> Another thing to consider is that we need to have peer review for all
> the changes done in the branch.  The implementation and/or design will
> need to be reviewed and may require extensive changes.

A good point. Again, the sooner we start, the sooner we're done, and the
less that needs to be reworked.

..Scott

-- 
Scott Robert Ladd
Coyote Gulch Productions (http://www.coyotegulch.com)
Software Invention for High-Performance Computing

Re: [RFC] Contributing tree-ssa to mainline

[Daniel Berlin]

> Err, no they aren't.  For example we have a host of -f options which 
> control
> debugging dumps rather than code generation.  That's wrong.
>

Are you referring to -fdump-tree*?

It is my understanding that this was already there when we started (and 
in fact, exists on the mainline too), we just extended it.

It seems like a simple renaming job would address that concern anyway.

Re: [RFC] Contributing tree-ssa to mainline

[Paul Brook]

On Saturday 17 January 2004 2:30 pm, Scott Robert Ladd wrote:
> Other Pros:
>
> We would have a working Fortran 95 compiler.

I'd be careful making claims like this:)

My current views on the status of gfortran is as follows:

Gfortran requires much of the tree-ssa infrastructure (GENERIC, etc.), and 
will probably not be merged without it. 

There is a good chance it will not be a complete replcement for g77 in time 
for gcc 3.5. Hopefully it will be usable as a f95 compiler, but it will most 
likley still have rough edges.

It is pretty much conformant to gcc coding standards. AFAIK the only thing 
we're missing is a full description of the gfortran specific compiler 
options.

g77 will probably never be made to work with tree-ssa. IMHO such effort would 
be better directed towards making gfortran work properly.

Paul

Re: [RFC] Contributing tree-ssa to mainline

[Scott Robert Ladd]

Paul Brook wrote:
> On Saturday 17 January 2004 2:30 pm, Scott Robert Ladd wrote:
>>We would have a working Fortran 95 compiler.
> 
> I'd be careful making claims like this:)

Oh, okay, just shoot me for being optimistic... :)

> There is a good chance it will not be a complete replcement for g77 in time 
> for gcc 3.5. Hopefully it will be usable as a f95 compiler, but it will most 
> likley still have rough edges.

On the other hand, can't people who need g77 simply stay with 3.4 and 
earlier?

One problem with the g77 is that lots of people use it, but none of them 
seem very active on these lists. The Ada folk have spoken well; who will 
advocate on behalf of g77's users?

> It is pretty much conformant to gcc coding standards. AFAIK the only thing 
> we're missing is a full description of the gfortran specific compiler 
> options.

Assuming some sanity and financial stability in my life -- a big 
assumption -- I'll look into some of the documentation issues.

> g77 will probably never be made to work with tree-ssa. IMHO such effort would 
> be better directed towards making gfortran work properly.

I agree.

-- 
Scott Robert Ladd
Coyote Gulch Productions (http://www.coyotegulch.com)
Software Invention for High-Performance Computing

Re: [RFC] Contributing tree-ssa to mainline

[Kaveh R. Ghazi]

 > From: Diego Novillo <dnovillo@redhat.com>
 > 
 > On Fri, 2004-01-16 at 20:51, Kaveh R. Ghazi wrote:
 > 
 > 
 > > But something is missing from Diego's call for discussion.  I think we
 > > should at least expect a more thorough status report (beyond the SPEC
 > > numbers which appear to be a wash.)  This should include tree-ssa's
 > > original goals and how close we are to meeting them.
 > > 
 > Very good point.  Thanks for bringing it up.  My original goal when I
 > started the project was very simple: modernize GCC's optimization
 > infrastructure.  To me that meant SSA, mostly because that's what I
 > brought with me from my University years.
 > 
 > [...]

Thanks Diego.  Your explanation and that of others in this thread has
really helped clarify the status of tree-ssa for me.  Based on what
I've heard, it sounds like you (collectively) have made terrific
progress.

I still think we should give high priority to some of the issues
raised like regressions and documentation, but these don't have to be
blockers as long as they is a commitment to address them.  (Again, my
mental model is the new C++ parser.)

There are a lot of reasons to suggest we should merge now or real soon
and at this point I'm inclined to agree with them.

However I'd like to hear the perspective of our release manager as
well as that of some of our global write maintainers who haven't been
immersed in the branch and haven't yet spoken up before we pull the
trigger on this.

		Thanks,
		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: [RFC] Contributing tree-ssa to mainline

[Kaveh R. Ghazi]

 > From: Diego Novillo <dnovillo@redhat.com>
 > 
 > > Now I know when a radical project is in it's infancy, from an advocacy
 > > perspective, it was in your interest a year ago to promise tree-ssa
 > > would create world peace, cure cancer, etc.
 >
 > No.  Not my style.  Since my initial posting in Feb'01 I've always
 > wanted only one thing: modernize GCC's optimization infrastructure.
 > Diego.

PS: Sorry if that came out too glib, perhaps I'm a bit jaded. :-)

--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: [RFC] Contributing tree-ssa to mainline

[Scott Robert Ladd]

Kaveh R. Ghazi wrote:
> I still think we should give high priority to some of the issues
> raised like regressions and documentation, but these don't have to be
> blockers as long as they is a commitment to address them.  (Again, my
> mental model is the new C++ parser.)

Documentation desperately needs to be considered, but it won't likely 
receive a priority so long as it is not funded by someone.

Documentating isn't as fun as coding. The same holds true for debugging 
and testing; they just aren't very sexy in comparison to forging new code.

Some people recognize this; one of my primary clients is paying me to 
document a free software project's algorithms and design. That project, 
however, is not GCC. Perhaps someone *is* being funded to write GCC 
documentation; I don't know who they are, though, or what their mandate 
might be.

-- 
Scott Robert Ladd
Coyote Gulch Productions (http://www.coyotegulch.com)
Software Invention for High-Performance Computing

Re: [RFC] Contributing tree-ssa to mainline

[Diego Novillo]

On Sat, 2004-01-17 at 12:12, Kaveh R. Ghazi wrote:

>  perhaps I'm a bit jaded. :-)
> 
Heh, don't worry.  Aren't we all? :)


Diego.

Re: [RFC] Contributing tree-ssa to mainline

[Kaveh R. Ghazi]

 > From: Scott Robert Ladd <coyote@coyotegulch.com>
 > 
 > Kaveh R. Ghazi wrote:
 > > I still think we should give high priority to some of the issues
 > > raised like regressions and documentation, but these don't have to be
 > > blockers as long as they is a commitment to address them.  (Again, my
 > > mental model is the new C++ parser.)
 > 
 > Documentation desperately needs to be considered, but it won't likely 
 > receive a priority so long as it is not funded by someone.
 > 
 > Documentating isn't as fun as coding. The same holds true for debugging 
 > and testing; they just aren't very sexy in comparison to forging new code.
 > 
 > Some people recognize this; one of my primary clients is paying me to 
 > document a free software project's algorithms and design. That project, 
 > however, is not GCC. Perhaps someone *is* being funded to write GCC 
 > documentation; I don't know who they are, though, or what their mandate 
 > might be.

Believe me, I am aware of the lack of sexiness of documentation.
Nevertheless IMHO we shouldn't throw up our hands and give up.

My understanding is that the tree-ssa project is actually very well
funded given the paid individuals dedicated to it for so long.  It
would seem simple good project management to include some
documentation hours in there somewhere.

Furthermore, the sexiness argument usually applies to more junior
programmers who don't understand the value of docs.  Even if we can't
find any paid hours to spend on this, I believe many of the developers
working on tree-ssa are seasoned enough to volunteer for this "dull"
task given they had the vision to begin this work in the first place.
(At least, that is my hope.)

This is certainly the right time to document the new infrastructure.

		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: [RFC] Contributing tree-ssa to mainline

[Robert Dewar]

Scott Robert Ladd wrote:

> Documentation desperately needs to be considered, but it won't likely 
> receive a priority so long as it is not funded by someone.

I don't see why documentation should be any more of an issue than coding

> Documentating isn't as fun as coding.

Documentation is *part* of coding, a fundamental and important part. My
view is that no code should ever be accepted for inclusion unless it is
fully documented. If people have fun doing a half baked job of coding
without properly documention, that's fine, but I do not find it a useful
contribution to *any* project, regardless of licensing or style of
development.

I have not looked at the tree-ssa code in detail. I will try to do so
in the near future. But in general terms, I would be opposed to its
inclusion if the documentation is incomplete or inadequate.

> Some people recognize this; one of my primary clients is paying me to 
> document a free software project's algorithms and design. That project, 
> however, is not GCC. Perhaps someone *is* being funded to write GCC 
> documentation; I don't know who they are, though, or what their mandate 
> might be.

The fact that something is Free Software should never be an excuse for
lack of documentation.

To me, a good programmer takes pride in the excellence of documentation
as an integral part of the code.

Re: [RFC] Contributing tree-ssa to mainline

[Joseph S. Myers]

On Sat, 17 Jan 2004, Robert Dewar wrote:

> Documentation is *part* of coding, a fundamental and important part. My
> view is that no code should ever be accepted for inclusion unless it is
> fully documented. If people have fun doing a half baked job of coding
> without properly documention, that's fine, but I do not find it a useful
> contribution to *any* project, regardless of licensing or style of
> development.

In that case, presumably as GNU Ada maintainer you consider the Ada front
end documentation included in GCC CVS as a fundamental part of the Ada
front end in GCC.  Is there any news on what can be expected in the way of
getting the documentation corresponding with the code for 3.4.0?  I don't
think anything has happened on this since
<http://gcc.gnu.org/ml/gcc-patches/2003-10/msg01892.html>.  The manuals
haven't had changes from ACT for a long time, but the corresponding
documentation changes should be routinely included along with the code
changes.

-- 
Joseph S. Myers
jsm@polyomino.org.uk

Re: [RFC] Contributing tree-ssa to mainline

[Scott Robert Ladd]

Kaveh R. Ghazi wrote:
> Believe me, I am aware of the lack of sexiness of documentation.
> Nevertheless IMHO we shouldn't throw up our hands and give up.

Agreed.

> My understanding is that the tree-ssa project is actually very well
> funded given the paid individuals dedicated to it for so long.  It
> would seem simple good project management to include some
> documentation hours in there somewhere.

Again, someone may be getting paid to write documentation for tree-ssa; 
I just don't know who. I think tree-ssa's advocates would have a better 
selling point if documentation stood ready for all to see.

At the moment, tree-ssa has a doxygen-generated API reference, a 
description of the SSA architecture, and various ancillary documents.

I'm trying to contribute to gfortran at the moment. I'm an old hand at 
coding, but compilers aren't my forte -- so it's a bit of a slog at the 
moment, and something I'm doing in my spare (i.e., "free-as-in-beer") 
time. Once I'm confident of my footing, I might consider writing a "this 
is how it works" document. I certainly know I could use such a thing 
right about now!

> Furthermore, the sexiness argument usually applies to more junior
> programmers who don't understand the value of docs.

It also applies to people who contribute "free-as-in-beer" time. If I'm 
going to work on something recreationally, I want to do something "fun" 
or that scratches an itch. I'm trying to work on two gfortran problems 
because they eliminate some nasty irritations for me. Perhaps the lack 
of documentation will also irritate me enough to work on it. ;)

-- 
Scott Robert Ladd
Coyote Gulch Productions (http://www.coyotegulch.com)
Software Invention for High-Performance Computing

Re: [RFC] Contributing tree-ssa to mainline

[Diego Novillo]

On Sat, 2004-01-17 at 06:16, Joseph S. Myers wrote:

> One key advantage of tree-ssa (as I see it) is a cleaned-up front-end
> interface.  As such it is a golden opportunity for a *documented*
> front-end interface,
>
Agreed.  We already have bits and pieces of documentation spread about
in papers and an initial GIMPLE documentation that Steven Bosscher
contributed last year.

I will take care of collecting all in a single document that explains
the FE interfaces and the optimization infrastructure.  Perhaps I could
even organize a talk about this for the next GCC Summit.


Diego.

Re: [RFC] Contributing tree-ssa to mainline

[Robert Dewar]

Joseph S. Myers wrote:
> On Sat, 17 Jan 2004, Robert Dewar wrote:

> In that case, presumably as GNU Ada maintainer you consider the Ada front
> end documentation included in GCC CVS as a fundamental part of the Ada
> front end in GCC.

Actually in my message I was talking of documentation of the code rather
than functional documentation, but indeed it would be good if the
functional documentation were up to date.

> Is there any news on what can be expected in the way of
> getting the documentation corresponding with the code for 3.4.0?

As you know we have been concentrating on synchronizing the code, and
that seems to be in fairly good shape. Getting similar procedures in
place for the documentation is certainly important and will be addressed
in the future. It's a little more problematical, since the doc sets are
not identical.

Re: [RFC] Contributing tree-ssa to mainline

[Scott Robert Ladd]

Robert Dewar wrote:
> Scott Robert Ladd wrote:
>> Documentating isn't as fun as coding.
> 
> Documentation is *part* of coding, a fundamental and important part. My
> view is that no code should ever be accepted for inclusion unless it is
> fully documented.

And I 100% agree; when I'm running a team, I demand docs as part of 
coding. I find this often at odds with the wishes of marketing and 
management -- but I explicitly look for clients who understand how 
important documentation is.

GCC, however, is a "free" project; I doubt anyone could dictate 
(successfully) that any patch include appropriate documentation, for 
example. And while you and I may recognize the value fo documenting our 
work, I find many programmers would rather code than comment.

> I have not looked at the tree-ssa code in detail. I will try to do so
> in the near future. But in general terms, I would be opposed to its
> inclusion if the documentation is incomplete or inadequate.

I've been looking at the tree-ssa documentation, in terms of 
understanding it well-enough to contribute to gfortran. I'm finding it a 
rather frustrating experience; I've written some of that off to my own 
inexperience with writing compilers, and some to a lack of "how this 
works" documentation.

As I said in another message: I think tree-ssa advocates will find their 
road easier to travel if they clearly and cleanly what tree-ssa does and 
how it benefits GCC as a whole.

> To me, a good programmer takes pride in the excellence of documentation
> as an integral part of the code.

On that, we agree completely.

-- 
Scott Robert Ladd
Coyote Gulch Productions (http://www.coyotegulch.com)
Software Invention for High-Performance Computing

Re: [RFC] Contributing tree-ssa to mainline

[Joseph S. Myers]

On Sat, 17 Jan 2004, Diego Novillo wrote:

> I will take care of collecting all in a single document that explains
> the FE interfaces and the optimization infrastructure.  Perhaps I could
> even organize a talk about this for the next GCC Summit.

The internals manual is where what documentation there is of the front end
interface (with some documentation of trees) presently is and where things
should link into.  It isn't presently wonderfully coherent in structure
but given the documentation written in some chapters of the manual, they
can always be reordered later as necessary to give a better-defined
structure.  (My old outline of a possible structure for the front-end
interface parts of the internals manual is at
<http://gcc.gnu.org/ml/gcc/2001-06/msg00125.html>.  I wrote a few bits of
this for sourcebuild.texi but the bulk of the front-end interface is
undocumented.  I'm not asking for you to write all of this, just to
document all the new and different front-end interfaces on tree-ssa.)

-- 
Joseph S. Myers
jsm@polyomino.org.uk

Re: [RFC] Contributing tree-ssa to mainline

[Mark Mitchell]

> I still think we should give high priority to some of the issues
> raised like regressions and documentation, but these don't have to be
> blockers as long as they is a commitment to address them.  (Again, my
> mental model is the new C++ parser.)

I can hardly object to that mental model, can I? :-)

I'll go back and look at this dicussion and offer what thoughts I have.

I tend to read the GCC mailing lists in a somewhat batchy fashion;
people should feel free to copy me explicitly on things that they
particularly want my input about.  Thank you for doing so here.

Thanks,

-- 
Mark Mitchell <mark@codesourcery.com>
CodeSourcery, LLC

Re: [RFC] Contributing tree-ssa to mainline

[Joseph S. Myers]

On Sat, 17 Jan 2004, Scott Robert Ladd wrote:

> GCC, however, is a "free" project; I doubt anyone could dictate 
> (successfully) that any patch include appropriate documentation, for 
> example. And while you and I may recognize the value fo documenting our 
> work, I find many programmers would rather code than comment.

We do dictate this.  Patches lacking documentation or testcases will be
rejected if I notice them.  Kenner sometimes complains about code lacking
sufficient comments.  (One thing tree-ssa adds is testsuite infrastructure
for testing that particular passes do particular optimisations - meaning
that once tree-ssa goes in, many optimisation patches which formerly
couldn't have had testcases will now require them.)

-- 
Joseph S. Myers
jsm@polyomino.org.uk

Re: [RFC] Contributing tree-ssa to mainline

[Joseph S. Myers]

On Sat, 17 Jan 2004, Robert Dewar wrote:

> As you know we have been concentrating on synchronizing the code, and
> that seems to be in fairly good shape. Getting similar procedures in

What is planned for this now 3.4 has branched?  Will Ada code changes
generally go to the 3.4 branch as well as mainline, or only bugfixes, or
only regression fixes, or some other rule?

-- 
Joseph S. Myers
jsm@polyomino.org.uk

Re: [RFC] Contributing tree-ssa to mainline

[Mark Mitchell]

On Fri, 2004-01-16 at 16:19, Diego Novillo wrote:
> Now that we are about to enter Stage 1 of 3.5, I wanted to solicit
> feedback regarding the merge of the tree-ssa branch into mainline.

I've now read the messages in this thread.

Diego, first, I would like to thank you for bringing up this issue and
presenting in such a balanced fashion.

Here are my thoughts on several of the key issues raised:

(1) Ada does not work with tree-ssa.

ACT does not see this as a blocking issue.  When the time comes, I think
that it's reasonable to ask that Ada people provide effort to do this
work, and I think it's also reasonable to ask tree-ssa people to commit
to helping them.  I have every confidence that will happen.

(2) G77 does not work with tree-ssa.

I do not see this as a blocking issue either, but it concerns me more,
in that nobody has come forward to say "I don't care about G77 working
with tree-ssa yet" in the same way that Dewar/Kenner have said that
about Ada.

(3) Coding standards, documentation issues, etc.

Clearly, these must be fixed before we merge the branch.  But Diego is
not asking to merge the branch *right now*; he is asking whether to
merge it for GCC 3.5.  Diego clearly understands that these issues must
be fixed before the merge occurs.  I'm sure that with concentrated
effort these issues could be fixed in the next few weeks on the branch.

(4) Mergin piecemeal vs. merging wholesale.

I think that if we decide to merge tree-ssa into the mainline for 3.5,
then it should be done wholesale.  If we do not decide to do that, it
might make sense to merge some of the changes in piecemeal.  But, I do
not think we should revisit the entire design space at this point.  I
have a very high confidence in the key tree-ssa architects to make good
decisions about the architecture, and all the evidence is that they
have.

(5) If we don't merge tree-ssa into 3.5, what will be in 3.5?

I'm not sure -- but I am sure there will be good things.  Apple is
working on compile-time performance improvements, and maybe
Objective-C++.  There will be new targets and other back-end
improvements.

Now, here are a few thoughts not relating so directly to particular
issues already raised.

(A) Ultimately, we want tree-ssa not because it is modern, but because
it provides user-visible improvements.  It's the better performance of
generated code, better compile-time performance, better language
support, and fewer bugs that our users are after.  To me, at this point,
it sounds like tree-ssa has the potential to help with all of those
things, except better language support.  But, it doesn't sound to me
like it has *realized* that potential in a sufficiently monotonic way. 
There are improvements in some areas, regressions in others.

(B) The new C++ parser is a fair analogy, although clearly the new C++
parser was a much smaller piece of work.  It is only about 15,000 lines
of code.  It only affects C++.  It's not nearly as risky to the overall
project as tree-ssa.

Therefore, my feeling is that tree-ssa is probably not ready for GCC
3.5.  My instinct is that we should try to get a GCC 3.5 release out on
something much more like our stated devlopment schedule, while tree-ssa
matures.  At the rate that has been happening, I would be astonished if
it weren't ready for GCC 3.6, especially if effort is invested in
dealing with the documentation issues and existing regressions.  I would
suggest that we focus less on adding new stuff and more on getting the
bugs out, improving the compile-time performance, and doing what can be
done to remove the RTL optimizers.  Waiting for GCC 3.6 gives gfortran
time to become a stronger replacement for G77, and for Ada to port to
tree-ssa; doing those things are benefits, even if not essential.

However, this is my preliminary opinion.

-- 
Mark Mitchell <mark@codesourcery.com>
CodeSourcery, LLC

Re: [RFC] Contributing tree-ssa to mainline

[Arnaud Charlet]

> What is planned for this now 3.4 has branched?  Will Ada code changes
> generally go to the 3.4 branch as well as mainline, or only bugfixes, or
> only regression fixes, or some other rule?

Clearly, we have put much more changes in 3.4 than for any other languages,
because the situation was unusual: Ada was not part of the requirements for
3.4, and was not in good shape.

Now that the situation is clearly better than what is used to be, it
seems reasonable to follow other language pratice. That is to say,
changes will by default go in the HEAD (as long as the HEAD builds fine
with Ada), and some very specific and critical fixes may go into the 3.4
branch.

Arno

Re: [RFC] Contributing tree-ssa to mainline

[Daniel Jacobowitz]

On Fri, Jan 16, 2004 at 07:19:01PM -0500, Diego Novillo wrote:
> 
> Now that we are about to enter Stage 1 of 3.5, I wanted to solicit
> feedback regarding the merge of the tree-ssa branch into mainline.

I'd like to offer another perspective, only slightly different.  Some
people are concerned, rightly, about the bugs that will be caused by
merging tree-ssa for 3.5.  But I'm concerned about the bugs that will
be neglected by not merging it.

There are currently nineteen suspended bugs targeted for tree-ssa; in
other words, nineteen reported bugs which are fixed on the tree-ssa
branch but are believed to be unfixable, or unreasonable to fix,
without tree-ssa.  Most of them (I didn't check the whole list, just a
random sample) were marked as fixed-on-tree-ssa within the last few
months.

I believe that if we don't merge tree-ssa for 3.5, especially if we
expect to merge it at a later date, this number will go up
dramatically.  It's already a nuisance that a lot of patches are told
"this is easier and better to do on tree-ssa", and it's going to get
worse as the infrastructure continues to improve.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFC] Contributing tree-ssa to mainline

[Andrew Pinski]

On Jan 17, 2004, at 11:01, Mark Mitchell wrote:
> (2) G77 does not work with tree-ssa.
>
> I do not see this as a blocking issue either, but it concerns me more,
> in that nobody has come forward to say "I don't care about G77 working
> with tree-ssa yet" in the same way that Dewar/Kenner have said that
> about Ada.

Well that is because there would be gfortran and G77 was really only in 
maintainer mode and
only be bug fixes if there were any.  There is already two enhancements 
to g77 which are
already fixed in gfortran.

Also gfortran needs some help but it looks like it getting some in the 
recent months.  There are still 28 bugs for gfortran, most are ICEs and 
some are rejects valid.  But most do not effect fortran 77 at all (but 
then I could be wrong).

What would help if the g77's testsuite to converted to be able to use 
for gfortran also.


Thanks,
Andrew Pinski
bug master

Re: [RFC] Contributing tree-ssa to mainline

[Richard Guenther]

On Sat, 17 Jan 2004, Daniel Jacobowitz wrote:

> On Fri, Jan 16, 2004 at 07:19:01PM -0500, Diego Novillo wrote:
> >
> > Now that we are about to enter Stage 1 of 3.5, I wanted to solicit
> > feedback regarding the merge of the tree-ssa branch into mainline.
>
> I'd like to offer another perspective, only slightly different.  Some
> people are concerned, rightly, about the bugs that will be caused by
> merging tree-ssa for 3.5.  But I'm concerned about the bugs that will
> be neglected by not merging it.

While I'm surely affected by these "bugs" (C++ with POOMA) and I'm looking
forward to some performance improvements with tree-ssa my experience with
tree-ssa for now is not so good in terms of time and memory consumption.

I'd rather suggest to go for a "quick" 3.5 release with rtlopt and maybe
new-ra merged, because while 3.4 is of superior quality compared to 3.3
for me, it quite seriously regressed in resulting performance.  This is
mainly due to the new loop-unroller which is said to be "fixed" on rtlopt
branch.

Tree-ssa needs to go to something like stage 3 (or at least stage 2) for
some time before it looks ready for me.

Just my 2 euro-cents,

Richard.

Re: [RFC] Contributing tree-ssa to mainline

[Steven Bosscher]

On Saturday 17 January 2004 18:50, Diego Novillo wrote:
> On Sat, 2004-01-17 at 06:16, Joseph S. Myers wrote:
> > One key advantage of tree-ssa (as I see it) is a cleaned-up front-end
> > interface.  As such it is a golden opportunity for a *documented*
> > front-end interface,
>
> Agreed.  We already have bits and pieces of documentation spread about
> in papers and an initial GIMPLE documentation that Steven Bosscher
> contributed last year.
>
> I will take care of collecting all in a single document that explains
> the FE interfaces and the optimization infrastructure.  Perhaps I could
> even organize a talk about this for the next GCC Summit.

I also have an updated cfg.texi.  I (and others) can distill other
documentation from the source files if the FSF (or the people who
contributed those source files) give us permission to put the extracted
text under the GFDL.  There is a lot of good comment in the code that
can be formatted for the manual.

Gr.
Steven

Re: [RFC] Contributing tree-ssa to mainline

[Steven Bosscher]

On Saturday 17 January 2004 20:34, Richard Guenther wrote:
> Tree-ssa needs to go to something like stage 3 (or at least stage 2) for
> some time before it looks ready for me.

It effectively has been in "stage 2.5" for some months now.  All
major new features are going on the LNO branch.

Gr.
Steven

Re: [RFC] Contributing tree-ssa to mainline

[law]

In message <C978C33E-48FB-11D8-AECF-000A95DA505C@dberlin.org>, Daniel Berlin wr
ites:
 >> Err, no they aren't.  For example we have a host of -f options which 
 >> control
 >> debugging dumps rather than code generation.  That's wrong.
 >>
 >
 >Are you referring to -fdump-tree*?
Yes.


 >It is my understanding that this was already there when we started (and 
 >in fact, exists on the mainline too), we just extended it.
Really.  Well, that's not really a good reason to extend broken practice.

 >It seems like a simple renaming job would address that concern anyway.
Yup.  But we can't honestly say we follow option/documentation conventions
knowing that this issue is still unresolved.


jeff

Re: [RFC] Contributing tree-ssa to mainline

[law]

In message <200401171457.29989.paul@codesourcery.com>, Paul Brook writes:
 >Gfortran requires much of the tree-ssa infrastructure (GENERIC, etc.), and 
 >will probably not be merged without it. 
Right.  Though it does not necessarily depend on the optimization aspects
of tree-ssa.

 >g77 will probably never be made to work with tree-ssa. IMHO such effort would
 >be better directed towards making gfortran work properly.
Agreed 100%.

jeff

Re: [RFC] Contributing tree-ssa to mainline

[Steven Bosscher]

On Saturday 17 January 2004 22:21, law@redhat.com wrote:
> In message <C978C33E-48FB-11D8-AECF-000A95DA505C@dberlin.org>, Daniel
> Berlin wr
>
> ites:
>  >> Err, no they aren't.  For example we have a host of -f options which
>  >> control
>  >> debugging dumps rather than code generation.  That's wrong.
>  >
>  >Are you referring to -fdump-tree*?
>
> Yes.
>
>  >It is my understanding that this was already there when we started (and
>  >in fact, exists on the mainline too), we just extended it.
>
> Really.  Well, that's not really a good reason to extend broken practice.
>
>  >It seems like a simple renaming job would address that concern anyway.
>
> Yup.  But we can't honestly say we follow option/documentation conventions
> knowing that this issue is still unresolved.

Honza and I would like to unify our tree and RTL debug dump handling.  I
guess we can move it up on the TODO list if this is an important issue.

Gr.
Steven

Re: [RFC] Contributing tree-ssa to mainline

[Diego Novillo]

On Sat, 2004-01-17 at 16:22, law@redhat.com wrote:
> In message <200401171457.29989.paul@codesourcery.com>, Paul Brook writes:
>  >Gfortran requires much of the tree-ssa infrastructure (GENERIC, etc.), and 
>  >will probably not be merged without it. 
> Right.  Though it does not necessarily depend on the optimization aspects
> of tree-ssa.
> 
It may indirectly.  In that the generated code w/o the tree optimizers
will likely be quite bad.  Also, if we merge GENERIC/GIMPLE w/o the
optimizers, users will probably hunt us down.

>  >g77 will probably never be made to work with tree-ssa. IMHO such effort would
>  >be better directed towards making gfortran work properly.
> Agreed 100%.
> 
Yes.


Diego.

Re: [RFC] Contributing tree-ssa to mainline

[Eric Christopher]

> Certainly it is our intention to do this conversion
> 

Awesome. I hadn't heard yet which is why the mail.

> > If ACT decides they don't have time to do this - then is it still a
> > blocker?
> 
> It's not a matter of not having time, but rather when the time can be
> found, and when this work can be completed. That is indeed a problem
> since this is quite a bit of work, and there are many other things
> competing for time. As with any company, AdaCore's priorities are set
> by its customers.

Amen.

-eric

-- 
Eric Christopher <echristo@redhat.com>

cfg.texi (was: [RFC] Contributing tree-ssa to mainline)

[Steven Bosscher]

On Saturday 17 January 2004 21:11, Steven Bosscher wrote:
> On Saturday 17 January 2004 18:50, Diego Novillo wrote:
> > On Sat, 2004-01-17 at 06:16, Joseph S. Myers wrote:
> > > One key advantage of tree-ssa (as I see it) is a cleaned-up front-end
> > > interface.  As such it is a golden opportunity for a *documented*
> > > front-end interface,
> >
> > Agreed.  We already have bits and pieces of documentation spread about
> > in papers and an initial GIMPLE documentation that Steven Bosscher
> > contributed last year.
> >
> > I will take care of collecting all in a single document that explains
> > the FE interfaces and the optimization infrastructure.  Perhaps I could
> > even organize a talk about this for the next GCC Summit.
>
> I also have an updated cfg.texi.

Like so.

Basically this is an update of the cfg.texi that was written
by Honza et.al., but somehow never made it into the manual.
It needs checking, so let's work on it and get it in.  When
this file is in, I'll see if I can find time to write down
all I can think of about GENERIC/GIMPLE.

Gr.
Steven

@c -*-texinfo-*-
@c Copyright (C) 2001, 2003, 2004 Free Software Foundation, Inc.
@c This is part of the GCC manual.
@c For copying conditions, see the file gcc.texi.

@c ---------------------------------------------------------------------
@c Control Flow Graph
@c ---------------------------------------------------------------------

@node CFG

@chapter Control Flow Graph
@cindex CFG, Control Flow Graph

A control flow graph (CFG) is a data structure built on top of the
intermediate code representation (RTL instruction chain or trees)
abstracting the control flow behavior of a function that is being
compiled.  The CFG is a directed graph where nodes are basic blocks
and edges represent possible control flows from one basic block to
another.

@menu
* Basic Blocks::           The basic block definition
* Edges::                  Types of edges and their representation
* Profile information::    Representation of frequencies and probabilities
* Maintaining the CFG::    Keeping the contorl flow graph up to date
* Liveness information::   Using and maintaining liveness information.
@end menu


@node Basic Blocks
@section Basic Blocks

@cindex basic block
@findex basic_block
A basic block is a straight-line sequence of code with only one entry
point and only one exit.  In GCC, basic blocks are represented using
the @code{basic_block} data type.

@findex next_bb, prev_bb, FOR_EACH_BB
Two pointer members of the @code{basic_block} data type are the
pointers @code{next_bb} and @code{prev_bb}.  These are used to keep
doubly linked chain of basic blocks in the same order as the
underlying instruction chain.  The chain is updated transparenly by
the functions manupulating the CFG.  The macro @code{FOR_EACH_BB} can
be used to visit all this order.

@findex BASIC_BLOCK
The @code{BASIC_BLOCK} array contains all basic blocks in an
unspecified order.  Each @code{basic_block} structure has a field that
holds a unique integer identifier @code{index} that is the index of
the block in the @code{BASIC_BLOCK} array.
The total number of basic blocks in the function is
@code{n_basic_blocks}.  Both the basic block indices and
the total number of basic blocks may vary during the compilation
process, as passes reorder, create, duplicate, and destroy basic
blocks.  The index for any block should never be greater than
@code{last_basic_blocks}.

@findex ENTRY_BLOCK_PTR, EXIT_BLOCK_PTR
Special basic blocks represent possible entry and exit points of a
function.  These blocks are called @code{ENTRY_BLOCK_PTR} and
@code{EXIT_BLOCK_PTR}.  These blocks do not contain any code, and are
not elements of the @code{BASIC_BLOCK} array.  Therefore they have
been assigned unique, negative index numbers.

Each @code{basic_block} also contains pointers to the first
instruction (the @dfn{head}) and the last instruction (the @dfn{tail})
or @dfn{end} of the basic block.  In fact, since the
@code{basic_block} data type is used to represent blocks in both major
intermediate representations of GCC (@code{tree} and RTL), there are
pointers to the head and end of a basic block for both
representations.

@findex NOTE_INSN_BASIC_BLOCK, CODE_LABEL
For RTL, these pointers are @code{rtx head, end}.  In the RTL function
representation, the head pointer always points either to
@code{NOTE_INSN_BASIC_BLOCK} or to @code{CODE_LABEL}, if present.
Basic block ends by control flow instruction or last instruction
before following @code{CODE_LABEL}.

@findex notes
In the RTL representation of a function, the instruction stream
contains not only the ``real'' instructions, but also @dfn{notes}.
Notes may or may not appear inside a basic block.  Any function that
moves or duplicates the basic blocks needs to take care of updating of
these notes.  Many of notes expect that code consists of linear
regions making such updates difficult.

@findex can_fallthru
Additionally the jump table vectors are represented as
``instructions'' inside the insn chain.  These vectors never appear in
the basic block and should be always placed just after table jump
instructions referencing them.  After removing the table-jump it is
difficult to eliminate the code computing address and referencing the
vector, so cleaning up the vectors is postponed until after liveness
analysis.   Thus the vectors may appear in the insn chain without any
purpose.  Before any edge is made @dfn{fall-thru}, the existence of
such construct in the way needs to be checked by calling
@code{can_fallthru} function.

@cindex block statement iterators
For the @code{tree} representation, the head and end of the basic block
are being pointed to by the @code{stmt_list} field, but this special
@code{tree} should never be referenced directly.  Instead, at the tree
level abstract containers and iterators are used to access
statements and expressions in basic blocks.  These iterators are
called @dfn{block statement iterators} (BSIs).  Grep for @code{^bsi}
in the various @file{tree-*} files.


@node Edges
@section Edges

@cindex edge in the flow graph
@findex edge
Edges represent possible control flow transfers from the end of some
basic block A to the head of another basic block B.  We say that A is
a predecessor of B, and B is a successor of A.  Edges are represented
in GCC with the @code{edge} data type.  Each @code{edge} acts as a
link between two basic blocks: the @code{src} member of an edge
points to the predecessor basic block of the @code{dest} basic block.
The members @code{pred} and @code{succ} of the @code{basic_block} data
type point to single linked lists of edges to the predecessors and
successorts of the block.  The edges are linked via the
@code{succ_next} and @code{pred_next} members of the @code{edge} data
type.

@findex fall-thru
There are various reasons why control flow may transfer from one block
to another.  One possibility is that some instruction, for example a
label, in a linearized instruction stream just always starts a new
basic block.  In this case a @dfn{fall-thru} edge links the basic
block to the first following basic block.  But there are several other
reasons why edges may be created.  In @code{flags} field of the the
@code{edge} data type is used to store information about the type of
edge we are dealing with.  Each edge is of one of the following types:

@table @emph
@item jumps
No type flags are set for edges corresponding to jump instructions.
These edges are used for unconditional or conditional jumps and in
RTL also for table jumps.  They are the easiest to manipulate as they
may be freely redirected if the flow graph is not in SSA form.

@item fall-thru
@findex EDGE_FALLTHRU, force_nonfallthru
Fall-thru edges are present in case where the basic block may continue
execution to the following one without branching.  These edges have
the @code{EDGE_FALLTHRU} flag set. Unlike other types of edges, these
edges must come into the basic block immediately following in the
instruction stream.  The function @code{force_nonfallthru} is
available to insert an unconditional jump in the case that redirection
is needed.  Note that this may require creation of a new basic block.

@item exception handling
@cindex exception handling
@findex EDGE_ABNORMAL, EDGE_EH
Exception handling edges represent possible control transfers from a
trapping instruction to an exception handler.  The definition of
``trapping'' varies.  In C++, only function calls can throw, but for
Java, exceptions like division by zero or segmentation fault are
defined and thus each instruction possibly throwing this kind of
exception needs to be handled as control flow instruction.  Exception
edges have the @code{EDGE_ABNORMAL} and @code{EDGE_EH} flags set.

@findex purge_dead_edges
When updating the instruction stream it is easy to change possibly
trapping instruction to non-trapping, by simply removing the exception
edge. The opposite conversion is difficult, but should not happen
anyway.  The edges can be eliminated via @code{purge_dead_edges} call.

@findex REG_EH_REGION, EDGE_ABNORMAL_CALL
In the RTL representation, the destination of an exception edge is
specified by @code{REG_EH_REGION} note attached to the insn.
In case of a trapping call the @code{EDGE_ABNORMAL_CALL} flag is set
too.  In the @code{tree} representation, this extra flag is not set.

@findex may_trap_p, tree_could_trap_p
In the RTL representation, the predicate @code{may_trap_p} may be used
to check whether instruction still may trap or not.  For the tree
representation, the @code{tree_could_trap_p} predicate is available,
but predicate only checks for possible memory traps, as in
dereferencing an invalid pointer location.


@item sibling calls
@cindex sibling call
@findex EDGE_ABNORMAL, EDGE_SIBCALL
Sibling calls or tail calls terminate the function in a non-standard
way and thus an edge to the exit must be present.
@code{EDGE_SIBCALL} and @code{EDGE_ABNORMAL} are set in such case.

@item computed jumps
@cindex computed jump
@findex EDGE_ABNORMAL
Computed jumps contain edges to all labels in the function referenced
from the code.  All those edges have @code{EDGE_ABNORMAL} flag set.
The edges used to represent computed jumps often cause compile time
performance problems, since functions consisting of many taken labels
and many computed jumps may have @emph{very} dense flow graphs, so
these edges need to be handled with special care.  During the earlier
stages of the compilation process, GCC tries to avoid such dense flow
graphs by factoring computed jumps.  For example, given the following
series of jumps, 

@example
  goto *x;
  [ ... ]

  goto *x;
  [ ... ]

  goto *x;
  [ ... ]
@end example

@noindent
factoring the computed jumps results in the following code sequence
which has a much simpler flow graph:

@example
  goto y;
  [ ... ]

  goto y;
  [ ... ]

  goto y;
  [ ... ]

y:
  goto *x;
@end example

However, the classic problem with this transformation is that it has a
runtime cost in there resulting code: An extra jump.  Therefore, the
computed jumps are un-factored in the later passes of the compiler.
Be aware of that when you work on passes in that area.  There have
been numerous examples allready where the compile time for code with
unfactored computed jumps caused some serious headaches.

@item nonlocal goto handlers
@cindex nonlocal goto handler
@findex EDGE_ABNORMAL, EDGE_ABNORMAL_CALL
GCC allows nested functions to return into caller using a @code{goto}
to a label passed to as an argument to the callee.  The labels passed
to nested functions contain special code to cleanup after function
call.  Such sections of code are referred to as ``nonlocal goto
receivers''.  If a function contains such nonlocal goto receivers, an
edge from the call to the label is created with the
@code{EDGE_ABNORMAL} and @code{EDGE_ABNORMAL_CALL} flags set.

@item function entry points
@cindex function entry point, alternate function entry point
@findex LABEL_ALTERNATE_NAME
By definition, execution of function starts at basic block 0, so there
is always an edge from the @code{ENTRY_BLOCK_PTR} to basic block 0.
There is no @code{tree} representation for alternate entry points at
this moment.  In RTL, alternate entry points are specified by
@code{CODE_LABEL} with @code{LABEL_ALTERNATE_NAME} defined.  This
feature is currently used for multiple entry point prologues and is
limited to post-reload passes only.  This can be used by back-ends to
emit alternate prologues for functions called from different contexts.
In future full support for multiple entry functions defined by Fortran
90 needs to be implemented.

@item function exits
In the pre-reload representation a function terminates after the last
instruction in the insn chain and no explicit return instructions are
used.  This corresponds to the fall-thru edge into exit block.  After
reload, optimal RTL epilogues are used that use explicit (conditional)
return instructions that are represented by edges with no flags set.

@end table


@node Profile information
@section Profile information

@cindex profile representation
In many cases a compiler must make a choice whether to trade speed in
one part of code for speed in another, or to trade code size for code
speed.  In such cases it is useful to know information about how often
some given block will be executed.  That is the purpose for
maintaining profile within the flow graph.
GCC can handle profile information obtained through @dfn{profile
feedback}, but it can also  estimate branch probabilities based on
statics and heuristics.

@cindex profile feedback
The feedback based profile is produced by compiling the program with
instrumentation, executing it on a train run and reading the numbers
of executions of basic blocks and edges back to the compiler while
re-compiling the program to produce the final executable.  This method
provides very accurate information about where a program spends most
of its time on the train run.  Whether it matches the average run of
course depends on the choice of train data set, but several studies
have shown that the behavior of a program usually changes just
marginally over different data sets.

@cindex Static profile estimation
@cindex branch prediction
@findex predict.def
When profile feedback is not available, the compiler may be asked to
attempt to predict the behavior of each branch in the program using a
set of heuristics (see @file{predict.def} for details) and compute
estimated frequencies of each basic block by propagating the
probabilities over the graph.

@findex frequency, count, BB_FREQ_BASE
Each @code{basic_block} contains two integer fields to represent
profile information: @code{frequency} and @code{count}.  The
@code{frequency} is an estimation how often is basic block executed
within a function.  It is represented as an integer scaled in the
range from 0 to @code{BB_FREQ_BASE}.  The most frequently executed
basic block in function is initially set to @code{BB_FREQ_BASE} and
the rest of frequencies are scaled accordingly.  During optimization,
the frequency of the most frequent basic block can both decrease (for
instance by loop unrolling) or grow (for instance by cross-jumping
optimization), so scaling sometimes has to be performed multiple
times.

@findex gcov_type
The @code{count} contains hard-counted numbers of execution measured
during training runs and is nonzero only when profile feedback is
available.  This value is represented as the host's widest integer
(typically a 64 bit integer) of the special type @code{gcov_type}.

Most optimization passes can use only the frequency information of a
basic block, but a few passes may want to know hard execution counts.
The frequencies should always match the counts after scaling, however
during updating of the profile information numerical error may
accumulate into quite large errors.

@findex REG_BR_PROB_BASE, EDGE_FREQUENCY
Each edge also contains a branch probability field: an integer in the
range from 0 to @code{REG_BR_PROB_BASE}.  It represents probability of
passing control from the end of the @code{src} basic block to the
@code{dest} basic block, i.e. the probability that control will flow
along this edge.   The @code{EDGE_FREQUENCY} macro is available to
compute how frequently a given edge is taken. There is a @code{count}
field for each edge as well, representing same information as for a
basic block.

The basic block frequencies are not represented in the instruction
stream, but in the RTL representation the edge frequencies are
represented for conditional jumps (via the @code{REG_BR_PROB}
macro) since they are used when instructions are output to the
assembly file and the flow graph is no longer maintained.

@cindex reverse probability
The probability that control flow arrives via a given edge to its
destination basic block is called @dfn{reverse probability} and is not
directly represented, but it may be easily computed from frequencies
of basic blocks.


@node Maintaining the CFG
@section Maintaining the CFG

An important task of each compiler pass is to keep both the control
flow graph and all profile information up-to-date.  Reconstruction of
the control flow graph after each pass is not an option, since it may be
very expensive and lost profile information cannot be reconstructed at
all.

GCC has two major intermediate representations, and both use the
@code{basic_block} and @code{edge} data types to represent control
flow.  Both representations share as much of the CFG maintainance code
as possible, but there are instances where the representations are
simply too different.  For these representation specific cases, a set
of @dfn{hooks} is defined so that each representation can provide its
own implementation.  These hooks are defined in @file{cfghooks.h}.
There are hooks for, amongst others, block splitting and merging, edge
redirection and for creating and deleting basic blocks.

Note that at present, the representation of control flow in the
@code{tree} representation is discarded before expanding to RTL.  Long
term the CFG should be maintained and ``expanded to the RTL
representation along with the function @code{tree} itself.

@menu
* RTL CFG::             RTL-specific issues in CFG maintainance
* Tree CFG::            Using and maintainint the @code{tree} CFG
@end menu

@node RTL CFG
@subsection RTL CFG

@findex BLOCK_FOR_INSN
At the moment, the basic block boundaries are maintained transparently
during emitting instruction, so there rarely is a need to move them
manually (such as in case someone wants to output instruction outside
basic block explicitly).  Each instruction has a defined
@code{BLOCK_FOR_INSN} value that represents pointer to the basic block
that contains the instruction.  Hence the basic block list may be
better viewed as integral part of instruction chain, than structure
built on the top of it.

@findex purge_dead_edges
Usually the optimization pass simplifies the instruction,
possibly eliminating some edges.  This may for example happen when
replacing a conditional jump with an unconditional jump, but also by
simplifying possibly trapping instruction to non-trapping while
compiling Java.  Updating of edges is not transparent and each
optimization pass is required to do so manually.  However only few
cases occur in practice.  The pass may call @code{purge_dead_edges} on
a given basic block to remove superfluous edges, if any.

@findex redirect_edge_and_branch, redirect_jump
Another common scenario is redirection of branch instructions, but
this is best modeled as redirection of edges in the control flow graph
and thus use of @code{redirect_edge_and_branch} is preferred over more
low level functions, such as @code{redirect_jump} that operate on RTL
chain only.

@findex find_sub_basic_blocks, split_block
A final common operation on basic blocks we should discuss is
inserting control flow instruction into the middle of a basic block.
The @code{find_sub_basic_blocks} may be used to split existing basic
block and add necessary edges, or @code{split_block} may be used when
instruction in middle of basic block wants to become target of branch
instruction.

@findex commit_insn_to_edge, commit_edge_insertions
For a global optimizer, a common operation is to split edges in the
flow graph and insert instruction to them.  This can be easily done
via function @code{commit_insn_to_edge} that emits instruction ''to
the edge'' caching it for later @code{commit_edge_insertions} call
that will care creation of new basic block where needed and flushing
the instruction to actual instruction stream.

While debugging the optimization pass, an @code{verify_flow_info}
function may be useful to find bugs in the control flow graph updating
code.


@node Tree CFG
@subsection Tree CFG

In principle, the control flow graph for the @code{tree}
representation is a not an integral part of the representation, in
that a function tree may be expanded without ever seen any flow graph
at all.  This happens when compiling without the tree optimization
enabled.  However, when the tree optimizations are enabled, and the
instruction stream is rewritten in SSA form, the CFG is very tightly
coupled with the instruction stream.  In particular, statement
insertion and removal has to be done with care.  In fact, the whole
@code{tree}  representation can not be easily used or maintained
without proper maintainance of the CFG simultaneously.

@cindex block statement iterators
When changes need to be applied to a function in its @code{tree}
representation, @dfn{block statement iterators} should be used.  These
iterators provide an integrated abstraction of the flow graph and the
instruction stream.  Block statement iterators iterators are
constructed using the @code{block_stmt_iterator} data structure and
several modifier are available, including the following:

@table @code
@item bsi_start
@findex bsi_start
This function initializes a @code{block_stmt_iterator} that points to
the first non-empty statement in a basic block.

@item bsi_last
@findex bsi_last
This function initializes a @code{block_stmt_iterator} that points to
the last statement in a basic block.

@item bsi_end_p
@findex bsi_end_p
This predicate is @code{true} if a @code{block_stmt_iterator}
represents the end of a basic block.

@item bsi_next
@findex bsi_next
This function takes a @code{block_stmt_iterator} and makes it point to
its successor.

@item bsi_prev (block_stmt_iterator *i)
@fitem bsi_prev
This function takes a @code{block_stmt_iterator} and makes it point to
its predecessor.

@item bsi_insert_after
@findex bsi_insert_after
This function inserts a statement after the @code{block_stmt_iterator}
passed in.  The final parameter determines whether the statement
iterator is updated to point to the newly inserted statement, or left
pointing to the original statement.

@item bsi_insert_before
@findex bsi_insert_before
This function inserts a statement before the @code{block_stmt_iterator}
passed in.  The final parameter determines whether the statement
iterator is updated to point to the newly inserted statement, or left
pointing to the original  statement.

@item bsi_insert_on_edge
@findex bsi_insert_on_edge, bsi_commit_edge_inserts
This function adds a stmt to the pending list of statements to insert
on an edge. No actual insertion is made until a call to
@code{bsi_commit_edge_inserts} is made.

@item bsi_remove
This function removes the @code{block_stmt_iterator} passed in and
rechains the remaining statements in a basic block, if any.

@end table


@node Maintaining profile information
@section Maintaining profile information
@findex redirect_edge_and_branch
A more delicate task than updating the control flow graph is to update
profile information.  Many of the functions to modify flow graph, like
@code{redirect_edge_and_branch}, do not have enough information to
easily update the profile, so updating it is in the majority of cases
left up to the caller.  It is difficult to discover bugs in the
profile updating code, because they manifest themselves only by
producing worse code, and checking profile consistency is not
possible because of  numeric error accumulation.  Hence, special
attention needs to be given to this issue in each pass that modifies
the CFG.

@findex REG_BR_PROB_BASE, BB_FREQ_BASE, count
It is important to point out that @code{REG_BR_PROB_BASE} and
@code{BB_FREQ_BASE} are both set low enough to be possible to compute
second power of any frequency or probability in the flow graph, it is
not possible to even square the @code{count} field, as modern CPUs are
fast enough to execute $2^32$ operations quickly.


@node Liveness information
@section Liveness information
@cindex Liveness representation
Liveness information is useful to determine whether register X is
``live'' at given point of program, ie. that it contains a value that
may be used at a later point in the program.  This information is
used, for instance, during register allocation pass, as the pseudo
registers need to be assigned to a unique hard register or to a stack
slot only if they are live.  The hard registers and stack slots may
be freely reused for other values when a register is dead.

@findex REG_DEAD, REG_UNUSED
The liveness information is stored partly in the RTL instruction chain
and partly in the flow graph.  RTL chain stores local information:
each  instruction may contain @code{REG_DEAD} note representing that
value of given register is no longer needed or @code{REG_UNUSED} note
representing that the value computed by instruction is never used.
The second is useful for instructions computing multiple values at
once.

@findex global_live_at_start, global_live_at_end
Each basic block contains bitmaps representing liveness of each
register at entry and exit of basic block (@code{global_live_at_start}
and @code{global_live_at_end}).  @code{flow.c} contains function to
compute liveness of each register at any given place in the
instruction stream using this information.

@findex BB_DIRTY, clear_bb_flags, update_life_info_in_dirty_blocks
Liveness is expensive to compute and thus it is desirable to keep it
up to date during optimization passes.  This can be easily
accomplished using @code{flags} field of basic block.  The functions
modifying instruction stream automatically set @code{BB_DIRTY} flag of
basic block, so the pass may simply use@code{clear_bb_flags} before
doing any modifications and then ask dataflow modulule via function
@code{update_life_info_in_dirty_blocks} to get liveness updated.

This scheme works reliably as long as no control flow graph
transformations are done.  The task of updating liveness after control
flow graph changes is more difficult as normal iterative data flow may
produce invalid results or get into cycle when the initial solution is
not bellow the desired one.  Only simple transformations, like
splitting basic blocks or emitting to the edge are safe, as functions
to implement them already know how to update liveness locally.

Re: cfg.texi (was: [RFC] Contributing tree-ssa to mainline)

[Steven Bosscher]

On Saturday 17 January 2004 23:53, Steven Bosscher wrote:
> On Saturday 17 January 2004 21:11, Steven Bosscher wrote:
> > On Saturday 17 January 2004 18:50, Diego Novillo wrote:
> > > On Sat, 2004-01-17 at 06:16, Joseph S. Myers wrote:
> > > > One key advantage of tree-ssa (as I see it) is a cleaned-up front-end
> > > > interface.  As such it is a golden opportunity for a *documented*
> > > > front-end interface,
> > >
> > > Agreed.  We already have bits and pieces of documentation spread about
> > > in papers and an initial GIMPLE documentation that Steven Bosscher
> > > contributed last year.
> > >
> > > I will take care of collecting all in a single document that explains
> > > the FE interfaces and the optimization infrastructure.  Perhaps I could
> > > even organize a talk about this for the next GCC Summit.
> >
> > I also have an updated cfg.texi.
>
> Like so.
>
> Basically this is an update of the cfg.texi that was written
> by Honza et.al., but somehow never made it into the manual.
> It needs checking, so let's work on it and get it in.  When
> this file is in, I'll see if I can find time to write down
> all I can think of about GENERIC/GIMPLE.

Oh, and yes this is older than the cfghooks.  I need to work on
a new section for that.

Gr.
Steven

Re: [RFC] Contributing tree-ssa to mainline

[Toon Moene]

Andrew Walrond wrote:

> I really like the sound of SSA going into 3.5, but it surely makes 3.4 a much 
> more important release with the emphasis on quaility rather than haste, 
> because we users ar going to depend on it for much longer, even beyond a 3.5 
> release if ada/g77 will be missing.
                  ^^^
Exactly, and that's why I want to fix as many g77 bugs in 3.4 before 
release.

I assume 3.4 will be the last GCC release with g77.

If gfortran isn't a complete replacement for g77 by the time 3.5 
(tree-ssa) is released, at least distributors of GNU/Linux OS's can 
offer the 3.4-g77 in /opt/bin.

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
GNU Fortran 95: http://gcc.gnu.org/fortran/ (under construction)

Re: [RFC] Contributing tree-ssa to mainline

[Toon Moene]

Joseph S. Myers wrote:

> One key advantage of tree-ssa (as I see it) is a cleaned-up front-end
> interface.

There must be a message in the fact that the g95 front end is about half 
the number of lines of C code the g77 front end is - despite the fact 
that Fortran 95 is a far more complicated language than Fortran 77.

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
GNU Fortran 95: http://gcc.gnu.org/fortran/ (under construction)

Re: [RFC] Contributing tree-ssa to mainline

[Toon Moene]

Andrew Pinski wrote:

> What would help if the g77's testsuite to converted to be able to use 
> for gfortran also.

Good point - thanks for reminding us.

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
GNU Fortran 95: http://gcc.gnu.org/fortran/ (under construction)

Re: [RFC] Contributing tree-ssa to mainline

[Phil Edwards]

On Sun, Jan 18, 2004 at 12:39:16AM +0100, Toon Moene wrote:
> Joseph S. Myers wrote:
> 
> >One key advantage of tree-ssa (as I see it) is a cleaned-up front-end
> >interface.
> 
> There must be a message in the fact that the g95 front end is about half 
> the number of lines of C code the g77 front end is - despite the fact 
> that Fortran 95 is a far more complicated language than Fortran 77.

Wow!  That's hellishly impressive.

-- 
America may be unique in being a country which has leapt
from barbarism to decadence without touching civilization.
  - John O'Hara

Re: [RFC] Contributing tree-ssa to mainline

[David Edelsohn]

>>>>> Richard Guenther writes:

Richard> I'd rather suggest to go for a "quick" 3.5 release with rtlopt and maybe
Richard> new-ra merged, because while 3.4 is of superior quality compared to 3.3
Richard> for me, it quite seriously regressed in resulting performance.  This is
Richard> mainly due to the new loop-unroller which is said to be "fixed" on rtlopt
Richard> branch.

	Other perfomance patches that do not depend on Tree-SSA include:
another GCSE performance patch from IBM Haifa that was considered too late
for GCC 3.4 and Modulo Scheduling (Software Pipelining).

David

Re: [RFC] Contributing tree-ssa to mainline

[Zack Weinberg]

Steven Bosscher <stevenb@suse.de> writes:

>
> Honza and I would like to unify our tree and RTL debug dump handling.  I
> guess we can move it up on the TODO list if this is an important issue.

If you do this, pretty please give the RTL dumps coherent long names,
with a notation like -drtl,cse,life for what now has to be spelled
-drsf.  (I would not cry if the single-letter dump switches went away,
as long as -da stays.)

zw

Re: [RFC] Contributing tree-ssa to mainline

[law]

In message <20040117135344.GH26819@atrey.karlin.mff.cuni.cz>, Jan Hubicka write
s:
 >There are other easy targets - NULL pointer ellimination for instance
 >that I was discussing with Jeff.
We could probably already turn off the RTL NULL pointer check elimination
code.  While I am aware of one case where the tree version misses something
the RTL version catches, that case is extremely rare.  Last I looked, it
triggered once per stage in a GCC bootstrap.

In contrast I've heard and seen firsthand the tree-ssa NULL pointer check
elimination code eliminating NULL pointer checks that the RTL version misses.

Jump threading/bypassing.  Right now we've got about 175 cases where the
RTL jump threader catches something that we should have detected at the
tree-ssa level (contrast this to > 3000 a few months ago).  I've got
patches in my local tree which bring that number down to around 40.

And (of course) I'm also seeing the tree-ssa code detect and thread a
number of jumps that the RTL threader is missing.

I haven't yet evaluated where we stand on making the RTL jump bypassing
code useless -- I know we're detecting some of that stuff in the tree-ssa
jump threader, but I really haven't evaluated it yet.

We're also reasonably close to being able to simplify CSE in a major
way -- specifically we're close to having the ability to turn off
the path following code in CSE1.

Jeff

Re: [RFC] Contributing tree-ssa to mainline

[law]

In message <200401171704.i0HH4WWn015521@caip.rutgers.edu>, "Kaveh R. Ghazi" wri
tes:
 >However I'd like to hear the perspective of our release manager as
 >well as that of some of our global write maintainers who haven't been
 >immersed in the branch and haven't yet spoken up before we pull the
 >trigger on this.
Most definitely.  

What I really want to get out of this discussion is what we as a group
think the criteria for merging ought to be.  We can look at a number of
different things, including but not limited to design and code reviews,
compile and runtime benchmarking, regression testing across a wide
range of platforms, front-end issues (Ada/g77), etc etc.

I realize we already have some policies regarding merges from branches
into the mainline.  What I'm not clear on is whether or not we need to
have a more rigorous set of policies for tree-ssa.

I don't necessarily want to rehash every design decision made by the
group, but I do believe that the tree-ssa developers must be able to
justify their design decisions to the larger developer community.

Similarly, I believe that code reviews are important and valuable.  While
we certainly can't force folks to review the code, if folks are willing
to review, then the tree-ssa developers ought to embrace that feedback
and "do the right thing" based on that feedback.  A code review is certainly
made more valuable if the reviewer has the design background.



I guess at the root of my concerns is that while a number of the tree-ssa
developers technically have the ability to approve a merge to the mainline
(assuming we meet the published criteria), I'm not sure that's necessarily
the right thing to do in this case.  And if it's not the right thing to do,
then what is the right course of action?  Those are the questions I want to
see us hash through.

jeff

Re: [RFC] Contributing tree-ssa to mainline

[Daniel Berlin]

>
> Similarly, I believe that code reviews are important and valuable.  
> While
> we certainly can't force folks to review the code, if folks are willing
> to review, then the tree-ssa developers ought to embrace that feedback
> and "do the right thing" based on that feedback.  A code review is 
> certainly
> made more valuable if the reviewer has the design background.

I have no problem with getting reviews of the code, or updating the 
code based on that feedback.  I'd like to make that abundantly clear.
I have a significant problem with some of the code not getting reviewed 
for large periods of time, which is the much more likely scenario (as 
unfortunate as that may be)
If you or Richard or Jason aren't the ones doing the reviews (since you 
guys wrote some of the code, or originally approved some of the passes 
on the tree-ssa branch, so presumably, you have no significant problem 
with it), then who exactly is?

I'd rather see multiple people try to review tree-ssa all at once, 
which admittedly, is a large job, but it's just as large as reviewing 
it separately!.
There is nothing to stop different reviewers from reviewing or 
commenting on different parts if it is submitted as a whole. They can 
easily make comments that may be directed at specific parts that people 
can clean up.
If it isn't done this way, then the likely outcome is some pieces of 
tree-ssa in the mainline, some pieces waiting for review, some pieces 
waiting for someone to cleanup, etc.    This would mean all performance 
numbers posted are invalid, and depending what *actually* gets in 
before 3.5, we may or may not have severe regressions.

I just don't see how a piecemeal review and submission of this branch 
is going to help anything, and I believe it is much more likely to hurt 
tree-ssa and gcc than it is to help.

Now, if someone is going to guarantee that all of the pieces tree-ssa 
will be reviewed in a timely manner, or at least will be reviewed and 
processed before 3.5 stage1 is over, then that would go a long way 
towards alleviating my concerns.

--Dan

Ada commits to branch (was: [RFC] Contributing tree-ssa to mainline)

[Laurent GUERBY]

On Sat, 2004-01-17 at 20:12, Arnaud Charlet wrote:
> Now that the situation is clearly better than what is used to be, it
> seems reasonable to follow other language pratice. That is to say,
> changes will by default go in the HEAD (as long as the HEAD builds fine
> with Ada), and some very specific and critical fixes may go into the 3.4
> branch.

May be it would be better to commit to both head and branch for a while,
especially if ACT chooses to use the branch for its own releases since
if tree-ssa is commited Ada won't work anymore on head?

Laurent

Re: Ada commits to branch (was: [RFC] Contributing tree-ssa to mainline)

[Arnaud Charlet]

> May be it would be better to commit to both head and branch for a while,
> especially if ACT chooses to use the branch for its own releases since
> if tree-ssa is commited Ada won't work anymore on head?

That would clearly be too much burden on our side: having to do two builds
and two make check-ada for each update is too much work.

Arno

Re: Ada commits to branch (was: [RFC] Contributing tree-ssa to mainline)

[Laurent GUERBY]

On Mon, 2004-01-19 at 13:23, Arnaud Charlet wrote:
> > May be it would be better to commit to both head and branch for a while,
> > especially if ACT chooses to use the branch for its own releases since
> > if tree-ssa is commited Ada won't work anymore on head?
> 
> That would clearly be too much burden on our side: having to do two builds
> and two make check-ada for each update is too much work.

If it's the only issue, I volunteer to do the check and commit
on the branch.

Laurent

Re: Ada commits to branch (was: [RFC] Contributing tree-ssa to mainline)

[Arnaud Charlet]

> If it's the only issue, I volunteer to do the check and commit
> on the branch.

Clearly there are more subtle issues, since the back-end interface will
likely change at some point, and the gigi files and make files will
be different.

Also, it's not just doing the check and commit blindly, you then need to
take responsibility for these changes, and if needed handle corresponding
PRs in bugzilla, among other things.

Arno

Re: Ada commits to branch (was: [RFC] Contributing tree-ssa to mainline)

[Laurent GUERBY]

On Mon, 2004-01-19 at 23:11, Arnaud Charlet wrote:
> > If it's the only issue, I volunteer to do the check and commit
> > on the branch.
> 
> Clearly there are more subtle issues, since the back-end interface will
> likely change at some point, and the gigi files and make files will
> be different.

At some level of change, it will indeed be safer to stop synchronizing
head and branch, but I believe we're not there yet.

It may be that tree-ssa is commited to HEAD (something I would welcome
for the long term benefit of GCC even if it breaks Ada for a while),
then only the branch will be usable for Ada users.

> Also, it's not just doing the check and commit blindly, you then need to
> take responsibility for these changes, and if needed handle corresponding
> PRs in bugzilla, among other things.

True, if PRs start to appear on branch and not on HEAD it means
that I've missed the "stop synchronizing" point and need to revert :).

Laurent

Re: [RFC] Contributing tree-ssa to mainline

[Kaveh R. Ghazi]

 > (B) The new C++ parser is a fair analogy, although clearly the new C++
 > parser was a much smaller piece of work.  It is only about 15,000
 > lines of code.  It only affects C++.  It's not nearly as risky to the
 > overall project as tree-ssa.

My use of the C++ parser analogy was not in reference to it's code
size or scope across the compiler.  Rather it was to your
attentiveness to fixing regressions in it and continuing to improve it
post-merge.

Jeff has offered such a commitment from Redhat towards tree-ssa here:
http://gcc.gnu.org/ml/gcc/2004-01/msg01304.html

I also agree with Joe that we should consider bumping to version 4.0
after we merge tree-ssa:
http://gcc.gnu.org/ml/gcc/2004-01/msg01408.html
I think it properly communicates the amount of change under the hood
to users.

Whether the merge and major version bump is the next release series or
the one following that is separate IMHO.  But if we can count on
dedicated support for fixing regression bugs and documentation now, I
think we should accept it and merge.  For various reasons, that
commitment may not be available six months or a year later which seems
to be the typical time between release series.

		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: [RFC] Contributing tree-ssa to mainline

[Gabriel Dos Reis]

"Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> writes:

| I also agree with Joe that we should consider bumping to version 4.0
| after we merge tree-ssa:
| http://gcc.gnu.org/ml/gcc/2004-01/msg01408.html
| I think it properly communicates the amount of change under the hood
| to users.

Seconded.

Merging tree-ssa into mainline, renaming the whole thing as the next
GCC-4.x.y series and allowing time for other front-ends to adjust 
and GCC developers to adjust to the new framework is, I believe, an
action we should seriously consider.  
In the meanwhile, we can continue work on the gcc-3_4-branch to
produce the GCC-3.4.x and (GCC-3.5.x if needed). 
If we don't do something like that, I'm afraid people will
"abandon" mainline and focuse on tree-ssa (which would become a de
factor mainline), therefore causing more confusions than would a proper
merge. 

The impression I've gotten from the thread that led to the sudden
gcc-3.4.x branching was that some major vendors are going to skip
GCC-3.4.x entirely, and they don't see any benefits in delaying
branching.  I suspect most of those vendors are going to concentrate
efforts on tree-ssa (if not merged to mainline).  I suspect that would
lead to another pshychodrama.

-- Gaby

Re: [RFC] Contributing tree-ssa to mainline

[Mark Mitchell]

> The impression I've gotten from the thread that led to the sudden
> gcc-3.4.x branching was that some major vendors are going to skip
> GCC-3.4.x entirely, and they don't see any benefits in delaying
> branching. 

It's a highly peripheral point to the main discussion, but, for the 
record, the creation of GCC 3.4 branch creation had nothing to do with 
any vendor input.

I had announced some time ago that the GCC 3.4 branch would be made when 
the number of regression fell below 100, and it did, so I made the branch.

-- Mark

Re: [RFC] Contributing tree-ssa to mainline

[Diego Novillo]

On Mon, 2004-01-19 at 20:39, Kaveh R. Ghazi wrote:

> Jeff has offered such a commitment from Redhat towards tree-ssa here:
> http://gcc.gnu.org/ml/gcc/2004-01/msg01304.html
> 
Yes.  We (Red Hat) are going to keep dedicating quite a bit of time to
tree-ssa whether it merges or not.

> I also agree with Joe that we should consider bumping to version 4.0
> after we merge tree-ssa:
> http://gcc.gnu.org/ml/gcc/2004-01/msg01408.html
> I think it properly communicates the amount of change under the hood
> to users.
> 
Agreed.

> Whether the merge and major version bump is the next release series or
> the one following that is separate IMHO.  But if we can count on
> dedicated support for fixing regression bugs and documentation now, I
> think we should accept it and merge.
>
As far as these requirements go, I would ask people to file bugzilla
reports against the branch detailing what needs to be taken care of.


Diego.

Re: [RFC] Contributing tree-ssa to mainline

[Gabriel Dos Reis]

Mark Mitchell <mark@codesourcery.com> writes:

| > The impression I've gotten from the thread that led to the sudden
| > gcc-3.4.x branching was that some major vendors are going to skip
| > GCC-3.4.x entirely, and they don't see any benefits in delaying
| > branching.
| 
| It's a highly peripheral point to the main discussion, but, for the
| record, the creation of GCC 3.4 branch creation had nothing to do with
| any vendor input.
| 
| I had announced some time ago that the GCC 3.4 branch would be made
| when the number of regression fell below 100, and it did, so I made
| the branch.

Thanks for the clarification!

-- Gaby

Re: [RFC] Contributing tree-ssa to mainline

[Scott Robert Ladd]

Gabriel Dos Reis wrote:
> "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> writes:
> 
> | I also agree with Joe that we should consider bumping to version 4.0
> | after we merge tree-ssa:
> | http://gcc.gnu.org/ml/gcc/2004-01/msg01408.html
> | I think it properly communicates the amount of change under the hood
> | to users.
> 
> Seconded.

Thirded. ;)

> Merging tree-ssa into mainline, renaming the whole thing as the next
> GCC-4.x.y series and allowing time for other front-ends to adjust 
> and GCC developers to adjust to the new framework is, I believe, an
> action we should seriously consider.  
 >
> In the meanwhile, we can continue work on the gcc-3_4-branch to
> produce the GCC-3.4.x and (GCC-3.5.x if needed). 
> If we don't do something like that, I'm afraid people will
> "abandon" mainline and focuse on tree-ssa (which would become a de
> factor mainline), therefore causing more confusions than would a proper
> merge. 

I was just going to write a message saying the above -- so I definitely 
concur with Gabriel on this. ;)

-- 
Scott Robert Ladd
Coyote Gulch Productions (http://www.coyotegulch.com)
Software Invention for High-Performance Computing

Re: [RFC] Contributing tree-ssa to mainline

[Andrew Haley]

Scott Robert Ladd writes:
 > Gabriel Dos Reis wrote:
 > > "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> writes:
 > > 
 > > | I also agree with Joe that we should consider bumping to version 4.0
 > > | after we merge tree-ssa:
 > > | http://gcc.gnu.org/ml/gcc/2004-01/msg01408.html
 > > | I think it properly communicates the amount of change under the hood
 > > | to users.
 > > 
 > > Seconded.
 > 
 > Thirded. ;)
 > 
 > > Merging tree-ssa into mainline, renaming the whole thing as the next
 > > GCC-4.x.y series and allowing time for other front-ends to adjust 
 > > and GCC developers to adjust to the new framework is, I believe, an
 > > action we should seriously consider.  

From the Java point of view, merging tree-ssa into mainline would make
my task easier.  I care rather less about whether we call it 3.5 or
4.0.

Andrew.

Re: [RFC] Contributing tree-ssa to mainline

[Gerald Pfeifer]

On Mon, 19 Jan 2004, Kaveh R. Ghazi wrote:
> I also agree with Joe that we should consider bumping to version 4.0
> after we merge tree-ssa:

I do understand your line of reasoning.  On the other hand, this change
should be relatively "harmless" from a user's point of view compared to
3.4 which will "break", a huge number, if not the majority, of C++
applications out there.

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

Re: [RFC] Contributing tree-ssa to mainline

[Robert Dewar]

> What is planned for this now 3.4 has branched?  Will Ada code changes
> generally go to the 3.4 branch as well as mainline, or only bugfixes, or
> only regression fixes, or some other rule?

Not determined yet, it depends partly on our decision internally of
what version of gcc to use for our next GNAT Pro release.

Re: [RFC] Contributing tree-ssa to mainline

[Robert Dewar]

Arnaud Charlet wrote:

> Now that the situation is clearly better than what is used to be, it
> seems reasonable to follow other language pratice. That is to say,
> changes will by default go in the HEAD (as long as the HEAD builds fine
> with Ada), and some very specific and critical fixes may go into the 3.4
> branch.

This certainly seems reasonable.

Re: [RFC] Contributing tree-ssa to mainline

[Diego Novillo]

On Tue, 2004-01-20 at 07:38, Richard Kenner wrote:
>     It's not a replacement for real documentation (that we're also working
>     on) but it makes the code much easier to understand.  And you don't
>     have to grep so much, if you see a functions you don't know yet, just
>     follow a link and see what it does.
> 
> I would *much* prefer to see all documentation in the sources.  The code needs
> to be self-contained and not to web pages someplace.  If you print out
> a set of files to read on an airplane, for example, you want to have all
> the necessary documentation in those files.
>
The documentation is *extracted* from the sources using doxygen. 
Please, do follow the documentation links from
http://gcc.gnu.org/projects/tree-ssa/


Diego.

Re: [RFC] Contributing tree-ssa to mainline

[Steven Bosscher]

On Tuesday 20 January 2004 13:38, Richard Kenner wrote:
>     It's not a replacement for real documentation (that we're also working
>     on) but it makes the code much easier to understand.  And you don't
>     have to grep so much, if you see a functions you don't know yet, just
>     follow a link and see what it does.
>
> I would *much* prefer to see all documentation in the sources.

We all do.  Which is why the documentation _is_ in the sources.

> The code
> needs to be self-contained and not to web pages someplace.

The code _is_ self-contained and the "web pages someplace" are extra.  And
they are not "someplace", you can generate them yourself.  Also in TeX
format, if you prefer that.  The content in the web pages is extracted from
the source files.  They are a bonus: They are the source in browsable format.

>  If you print
> out a set of files to read on an airplane, for example, you want to have
> all the necessary documentation in those files.

So I repeat:
The documentation _is_ in the sources.  _And_ in the web pages.  This
is more source documentation than we have now.  The web pages are extra.

This has been discussed in length in many threads in late 2002.

Gr.
Steven

Re: [RFC] Contributing tree-ssa to mainline

[Daniel Jacobowitz]

On Tue, Jan 20, 2004 at 07:38:39AM -0500, Richard Kenner wrote:
>     It's not a replacement for real documentation (that we're also working
>     on) but it makes the code much easier to understand.  And you don't
>     have to grep so much, if you see a functions you don't know yet, just
>     follow a link and see what it does.
> 
> I would *much* prefer to see all documentation in the sources.  The code needs
> to be self-contained and not to web pages someplace.  If you print out
> a set of files to read on an airplane, for example, you want to have all
> the necessary documentation in those files.

Did you take a look at it?  You've been given at least three links to
it already.  It is extracted from the sources via doxygen.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFC] Contributing tree-ssa to mainline

[Richard Kenner]

    It's not a replacement for real documentation (that we're also working
    on) but it makes the code much easier to understand.  And you don't
    have to grep so much, if you see a functions you don't know yet, just
    follow a link and see what it does.

I would *much* prefer to see all documentation in the sources.  The code needs
to be self-contained and not to web pages someplace.  If you print out
a set of files to read on an airplane, for example, you want to have all
the necessary documentation in those files.

Re: [RFC] Contributing tree-ssa to mainline

[Steven Bosscher]

On Tuesday 20 January 2004 12:49, Richard Kenner wrote:
>     But the comments from the beginning of each function is the
>     *specification* of the function and not the *implementation*, this is
>     where the documentation comes from.
>
> That's correct, so I think we're talking about two different things.
> The issue that was being raised was documentation *in the source* and
> it sounded like you were saying that the documentation specification
> of the function was derived from that of the implementation.
>
> So what *is* the documentation that's derived from this?
>

Go have a look:
http://people.redhat.com/dnovillo/pub/tree-ssa/doc/html/index.html

It's not a replacement for real documentation (that we're also working
on) but it makes the code much easier to understand.  And you don't
have to grep so much, if you see a functions you don't know yet, just
follow a link and see what it does.

Gr.
Steven

Re: [RFC] Contributing tree-ssa to mainline

[Richard Kenner]

    But the comments from the beginning of each function is the
    *specification* of the function and not the *implementation*, this is
    where the documentation comes from.

That's correct, so I think we're talking about two different things.
The issue that was being raised was documentation *in the source* and
it sounded like you were saying that the documentation specification
of the function was derived from that of the implementation.

So what *is* the documentation that's derived from this?

    If this is not true in your Ada sources, then you are not following
    the coding style and every patch should be rejected here forth until
    you or another Ada person fixes this.

In Ada, the specification and implementation of a function are in two
different files (or two different places in the same file for local functions)
and the documentation for each is located at the corresponding location.

Re: [RFC] Contributing tree-ssa to mainline

[Diego Novillo]

On Mon, 2004-01-19 at 23:25, Richard Kenner wrote:
>     The API documentation is published nightly, created directly from the
>     source code comments.  
> 
> I don't follow.  The source code comments within a function describe the
> *implementation* of a function: the API documentation needs to describe
> the *specification* of a function.  These are two different things.
>
I never said the comments were inside each function.

http://people.redhat.com/dnovillo/pub/tree-ssa/doc/html/tree-ssa_8c.html#a63

I also never said the documentation was perfect.  I want folks outside
the project to offer feedback in the form of bugzilla reports (adding to
PR13756 should suffice).


Diego.

Re: [RFC] Contributing tree-ssa to mainline

[Robert Dewar]

> If this is not true in your Ada sources, then you are not following the 
> coding
> style and every patch should be rejected here forth until you or 
> another Ada
> person fixes this.

Actually it would be quite wrong in Ada to put the specification of the
function at the start of the code for the function, it belongs in the
package spec, not in the package body. Ada is not C!

Re: [RFC] Contributing tree-ssa to mainline

[Andrew Pinski]

On Jan 19, 2004, at 20:25, Richard Kenner wrote:

>     The API documentation is published nightly, created directly from 
> the
>     source code comments.
>
> I don't follow.  The source code comments within a function describe 
> the
> *implementation* of a function: the API documentation needs to describe
> the *specification* of a function.  These are two different things.

But the comments from the beginning of each function is the 
*specification*
of the function and not the *implementation*, this is where the 
documentation
comes from.

If this is not true in your Ada sources, then you are not following the 
coding
style and every patch should be rejected here forth until you or 
another Ada
person fixes this.


Thanks,
Andrew Pinski

Re: [RFC] Contributing tree-ssa to mainline

[Richard Kenner]

    The API documentation is published nightly, created directly from the
    source code comments.  

I don't follow.  The source code comments within a function describe the
*implementation* of a function: the API documentation needs to describe
the *specification* of a function.  These are two different things.

Re: [RFC] Contributing tree-ssa to mainline

[Diego Novillo]

On Mon, 2004-01-19 at 22:13, Geert Bosch wrote:
> On Jan 19, 2004, at 18:43, Daniel Berlin wrote:
> > Anyway,  It would be more productive if we were to try to concentrate 
> > on a specific set of merge criteria for tree-ssa, than continue to 
> > discuss the benefits or disadvantages of it (since it seems clear the 
> > overwhelming number of people think it has great benefit already)
> 
> The single biggest issue is documentation.
>
We try to keep it fairly detailed and complete.  The API documentation
is published nightly, created directly from the source code comments. 
As with any evolving piece of code, I will not guarantee that the
documentation is complete, but it should not be hard to derive .texi
documentation out of it.

>  As you say, there are thirty
> optimization passes. That means that there should be thirty descriptions
> of  these passes
>
Fewer, actually.  Some passes are repeated more than once.

> So I would like to push for strict standards for documentation.
> All new code must meet the documentation standards *before* merging.
> Also, any old code that may be affected by the changes needs to be
> reviewed and stale comments need to be updated. In my opinion everything
> else is secondary.
> 
This goes again to my request for peer review.  All the API
documentation is available online.  You don't need to even check-out the
branch.  Follow the links from http://gcc.gnu.org/projects/tree-ssa/
You will find high-level design documents and API documentation.  We
need bugzilla reports that point out specific bits that are missing.  I
have created PR13756 to begin tracking documentation issues.  Feel free
to add what you think is missing.


Thanks.  Diego.

Re: [RFC] Contributing tree-ssa to mainline

[Geert Bosch]

On Jan 19, 2004, at 18:43, Daniel Berlin wrote:
> Anyway,  It would be more productive if we were to try to concentrate 
> on a specific set of merge criteria for tree-ssa, than continue to 
> discuss the benefits or disadvantages of it (since it seems clear the 
> overwhelming number of people think it has great benefit already)

The single biggest issue is documentation. As you say, there are thirty
optimization passes. That means that there should be thirty descriptions
of  these passes: specify what the necessary preconditions are before
running the pass (what information needs to be up-to-date etc), what
invariants are maintained, what transformations the pass performs, what
transformations are not done and why (like other pass does xyz), and
what postconditions hold. Also include references to literature where
appropriate, including  deviations from the described algorithms as
well as pitfalls encountered during implementation. Only comments can
describe why certain paths have not been taken.

All data structures need documentation, statements about initialization
and invariants. Every function needs a comment describing its effects
at a sufficiently high level, including precise meaning of all formal
parameters and effects on global data structures.

As explained before, one of the main goals of tree-ssa is to improve
maintainability of the compiler by moving to more standard and easy
to  modify algorithms instead of organically grown intricate webs of
functionality. This argument for change only holds water if the
replacements algorithms are well-documented. In a way it is worse to
have newly written poorly documented code, than similar code that has
been around for ages.

So I would like to push for strict standards for documentation.
All new code must meet the documentation standards *before* merging.
Also, any old code that may be affected by the changes needs to be
reviewed and stale comments need to be updated. In my opinion everything
else is secondary.

   -Geert

Re: [RFC] Contributing tree-ssa to mainline

[Dale Johannesen]

On Jan 19, 2004, at 3:43 PM, Daniel Berlin wrote:
> I'd like to point out that this whole thread is still getting us 
> somewhere, and not just filling up inboxes.
> Seriously though, I think we've reached the point of diminishing 
> gains. We now know how everyone feels.
> It appears that this is "most people are in favor, some people are 
> against", but everyone seems to have some specific criteria they want 
> met before merging.
> Anyway,  It would be more productive if we were to try to concentrate 
> on a specific set of merge criteria for tree-ssa, than continue to 
> discuss the benefits or disadvantages of it (since it seems clear the 
> overwhelming number of people think it has great benefit already)

IMO the important question to ask is, will tree-ssa be the basis for 
3.5?  If the answer to this is
yes, I believe we should merge immediately even if the current state is 
not what we would like
it to be.  That will reduce everyone's maintenance burden.

> I'd also like to point out that tree-ssa is, by various benchmarks 
> pointed out earlier, in the worst case, slightly slower than the 
> mainline in compile time, even though it adds *30* optimization 
> passes.
> That's right.
> Thirty.
> Check tree-optimize if you don't believe me.
> That's quite an accomplishment in and of itself if you ask me.

It suggests that one pass does not take a lot of time, provided you 
aren't doing much in that pass.
This is in line with my experience (and other people's) on other 
compilers.

Re: [RFC] Contributing tree-ssa to mainline

[Joe Buck]

On Fri, Jan 16, 2004 at 11:10:14PM -0700, law@redhat.com wrote:
> OK.  Let's take everything you've said as a given and let's ponder what
> actually has been done with Ada to make it work with already existing
> infrastructure mainline.  Specifically function at a time mode.  We've had
> function at a time mode for a few years now, but yet we still have seen
> little movement in the Ada front-end to support that mode.
> 
> Given the lack of movement on that front, how can we realistically expect
> any movement on something like tree-ssa?  Particularly when tree-ssa
> depends on function at a time mode?

Well, if we go ahead and release a tree-ssa GCC, and it's a big success
and clearly superior, to the point where fewer and fewer developers are
left who are interested in supporting the "old" GCC, at some point point
the pressure builds from knowledgeable GNAT users for a tree-ssa based
implementation, and the motivation will increase to respond to that
pressure.

What I'm hearing is that the Ada folks don't think that going to tree-ssa
and leaving them behind is a problem, so I'm willing to take them at their
word.

> Realistically, if we are going to make tree-ssa a complete non-starter
> because the Ada front-end isn't going to work and its maintainers are
> not showing any willingness to put forth the effort to make it work with
> already existing infrastructure, then, well, why bother with tree-ssa
> at all.  I'll take my time and effort to some other non-GCC project
> where I can actually make a difference.

I very much want to see a tree-ssa based GCC, and delays in converting the
Ada front end should not affect this (though they might require us to keep
the 3.4.x infrastructure around for longer).

Re: [RFC] Contributing tree-ssa to mainline

[Daniel Berlin]

I'd like to point out that this whole thread is still getting us 
somewhere, and not just filling up inboxes.
Seriously though, I think we've reached the point of diminishing gains. 
We now know how everyone feels.
It appears that this is "most people are in favor, some people are 
against", but everyone seems to have some specific criteria they want 
met before merging.

I'd also like to point out that tree-ssa is, by various benchmarks 
pointed out earlier, in the worst case, slightly slower than the 
mainline in compile time, even though it adds *30* optimization passes.
That's right.
Thirty.
Check tree-optimize if you don't believe me.
That's quite an accomplishment in and of itself if you ask me.

Anyway,  It would be more productive if we were to try to concentrate 
on a specific set of merge criteria for tree-ssa, than continue to 
discuss the benefits or disadvantages of it (since it seems clear the 
overwhelming number of people think it has great benefit already)


You friendly neighborhood cat herder,
Dan

Re: [RFC] Contributing tree-ssa to mainline

[Richard Kenner]

    I'm not aware of any code in GCC to "figure out the GIV offset from all
    the computations in RTL"?


loop.c:check_insn_for_givs

Re: [RFC] Contributing tree-ssa to mainline

[Joe Buck]

On Mon, Jan 19, 2004 at 03:48:00PM +0100, Lars Segerlund wrote:
> 
>  I agree with Richard, there is no problem, if the Ada compiler won't run with tree-ssa then the ada people have to run 3.4 ....

This might be an argument for making the first tree-ssa release 4.0.

If, instead, we decide that tree-ssa will be 3.5, and we support Ada and
g77 by continuing the lifetime of 3.4, at some point me might need to make
an ABI-incompatible change somewhere, requiring a bumping of the minor
version number of 3.4.  However, if we've already put out a 3.5 release,
then there is no room in between.

Re: [RFC] Contributing tree-ssa to mainline

[tm_gccmail]

On Mon, 19 Jan 2004, Richard Kenner wrote:

>     But any alias/loop optimization cannot really be done on targets like
>     IA64 with almost no offset.  The IA64 has only room for a zero offset,
>     every thing is done in index form.
> 
> That doesn't matter.  You'd figure out the GIV offset from all the
> computations in RTL.  We do that now.

I'm not aware of any code in GCC to "figure out the GIV offset from all
the computations in RTL"?

AFAIK the closest we came to this was Sanjiv's patch for Debray alias
analysis, but this was rejected due to the excessive compile-time
overhead.

Toshi

Re: [RFC] Contributing tree-ssa to mainline

[Joe Buck]

On Fri, Jan 16, 2004 at 10:24:08PM -0500, Richard Kenner wrote:
>     Expecting tree-ssa to produce code better by a factor of two is simply
>     unreasonable.
> 
> In general, of course.  But if it is really allowing new classes of
> optimizations to be performed (which was the argument to justify the new
> infrastructure), it should be possible to construct test cases that show
> that sort of performance improvement (factors of two or more).

There are certain cases where tree-ssa *already* produces better code by a
factor of two or more.  See, for example PR 12747.

Re: [RFC] Contributing tree-ssa to mainline

[Richard Kenner]

    But any alias/loop optimization cannot really be done on targets like
    IA64 with almost no offset.  The IA64 has only room for a zero offset,
    every thing is done in index form.

That doesn't matter.  You'd figure out the GIV offset from all the
computations in RTL.  We do that now.

Re: [RFC] Contributing tree-ssa to mainline

[Andrew Pinski]

On Jan 19, 2004, at 07:07, Richard Kenner wrote:
> Good, because that's my concern: the form of the subscript information 
> is
> critical to many high-level loop optimizations.  If you're going to 
> have to
> figure that out from an address computation, you're giving up much of 
> the
> benefit of doing that optimization on trees instead of RTL>

But any alias/loop optimization cannot really be done on targets like 
IA64 with almost no
offset.  The IA64 has only room for a zero offset, every thing is done 
in index form.


Thanks,
Andrew Pinski

Re: [RFC] Contributing tree-ssa to mainline

[Richard Kenner]

    Well, I know nothing about Ada so I'm not sure what you mean by that
    remark.  That's why I was asking for specific examples.  Annotated, if
    possible.

OK.  Here's a test program:

procedure Tparray (X: Integer) is
   type Barr is array (Integer range <>) of Boolean;
   pragma Pack (Barr);		-- So we have a packed array of 1 bit
   Y: constant Integer := 31;	-- Here's a variable whose value we know.

   subtype Barr1 is Barr(1..X); -- This type has variable size.
   subtype Barr2 is Barr(1..Y); -- ... and this one has a fixed size (31 bits).

   --  Now we have two identical functions, one on each type.

   function F1 (A, B : Barr1) return Barr1 is
      Arr: Barr1 := A;
   begin
      Arr (2) := False;
      return Arr xor B;
   end F1;

   function F2 (A, B : Barr2) return Barr2 is
      Arr: Barr2 := A;
   begin
      Arr (2) := False;
      return Arr xor B;
   end F2;
begin
   null;
end Tparray;

Now here's the Ada expanded code for this.  Note the very different forms
of tparray__f1 and tparray__f2:

Source recreated from tree for Tparray (body)
---------------------------------------------

with system.system__unsigned_types;
with system.system__bit_ops;
with system;
with system.system__secondary_stack;

procedure tparray (x : integer) is
   type tparray__barr is array (-16#8000_0000# .. 16#7FFF_FFFF#
     range <>) of boolean;
   pragma pack (tparray__barr);
   y : constant integer := 31;
   subtype tparray__barr1 is tparray__barr (1 .. x);
   subtype tparray__barr2 is tparray__barr (1 .. 31);
   freeze tparray__barr []
   freeze tparray__barr1 []
   freeze tparray__barr2 []
   
   function tparray__f1 (a : tparray__barr1; b : tparray__barr1)
     return tparray__barr1 is
      arr : tparray__barr1 := a;
   begin
      arr (0) := system__unsigned_types__packed_byte!(arr (0) and 16#FD#);
      null;
      T3b : tparray__barr1;
      system__bit_ops__bit_xor (arr'address, tparray__Tbarr1P1'
        range_length, b'address, tparray__Tbarr1P1'range_length, T3b'
        address);
      return T3b;
   end tparray__f1;
   
   function tparray__f2 (a : tparray__barr2; b : tparray__barr2)
     return tparray__barr2 is
      arr : tparray__barr2 := a;
   begin
      arr := tparray__barr2___XP1!(arr and 16#FFFF_FFFD#);
      null;
      return tparray__barr2!(arr xor b);
   end tparray__f2;
begin
   null;
   return;
end tparray;

Re: [RFC] Contributing tree-ssa to mainline

[Jeff Sturm]

On 19 Jan 2004, Tom Tromey wrote:
> Right now I think the tree-ssa benefits to Java are more potential
> than actual.  In the future we hope to get array bounds check
> elimination, elimination of redundant type checks, and perhaps
> elimination of redundant class initialization.

Improved null pointer checking in tree-ssa may already help Java.  The RTL
optimization did not handle aggregates well, as in:

  s->a = 1; if (s != NULL) ...

Jeff

Re: [RFC] Contributing tree-ssa to mainline

[Robert Dewar]

Diego Novillo wrote:

> Instead of emitting runtime calls, would it be possible to emit tree
> codes with well defined semantics?  On finding them, the optimizers
> would know that it's not just an arbitrary function call for instance
> (perhaps adding attributes to the libcall).
> 
> But I'm oversimplifying.  We would have to talk about specific cases.

One specific issue that has been pending for ten years now is having
gcc generate reasonable code for arithmetic overflow checking. Right
now, GNAT really generates horrible stuff in the front end to make up
for this defic`iency. That to me is step #1 in improving the checking
situation for GNAT.

The code is nasty enough that we don't turn on arithemtic overflow
checking by default, which really is not very Ada :-)

Re: [RFC] Contributing tree-ssa to mainline

[Andrew Haley]

Tom Tromey writes:
 > >>>>> "Richard" == Richard Kenner <kenner@vlsi1.ultra.nyu.edu> writes:
 > 
 > >     Even if tree-SSA didn't made important speedups for common C programs I
 > >     think this is not problem as long as it is not making C worse and do
 > >     make C++ and Java better.
 > 
 > Richard> Can similar cases as those shown for C++ be constructed and
 > Richard> measured for Java?
 > 
 > I wouldn't expect to find Java equivalents of the C++ abstraction
 > penalty tests, since Java doesn't have stack-allocated objects.  (My
 > understanding is that we improve on these tests due to being able to
 > split up and register-ize stack-allocated objects...)
 > 
 > Right now I think the tree-ssa benefits to Java are more potential
 > than actual.  In the future we hope to get array bounds check
 > elimination, elimination of redundant type checks, and perhaps
 > elimination of redundant class initialization.

And stack-allocated objects; therefore...

Andrew.

Re: [RFC] Contributing tree-ssa to mainline

[Geert Bosch]

On Jan 19, 2004, at 12:51, Diego Novillo wrote:
> Instead of emitting runtime calls, would it be possible to emit tree
> codes with well defined semantics?  On finding them, the optimizers
> would know that it's not just an arbitrary function call for instance
> (perhaps adding attributes to the libcall).
>
> But I'm oversimplifying.  We would have to talk about specific cases.

There are definitely cases where we should do this. For example,
for overflow checks in integer addition and multiplication, we now
use a wider type for the arithmetic (or library routines for wide types)
and check the result against bounds. Having tree codes with
language-defined overflow semantics would allow the back end to
expand to proper instructions with trap-on-overflow or jump on
condition code. How does Java deal with this issue?

   -Geert

Re: [RFC] Contributing tree-ssa to mainline

[Richard Kenner]

    Instead of emitting runtime calls, would it be possible to emit tree
    codes with well defined semantics?  On finding them, the optimizers
    would know that it's not just an arbitrary function call for instance
    (perhaps adding attributes to the libcall).
    
    But I'm oversimplifying.  We would have to talk about specific cases.

You are oversimplifying.  There is a *huge* amount of code generated
that has subtle dependencies on these things.

Just as one example, the representation and generated code for packed
array of Boolean is completely different if the array bounds are constant
and small (say 1..32) vs. if they are variable.

There's no practical way to represent all the different possibilities
and expect language-independent code to choose one based on constant
propagation: it has to be done in the front end or not at all.

Re: [RFC] Contributing tree-ssa to mainline

[Diego Novillo]

On Mon, 2004-01-19 at 12:56, John R. Shannon wrote:

> On Monday 19 January 2004 10:51 am, Diego Novillo wrote:
> > On Mon, 2004-01-19 at 12:42, Geert Bosch wrote:
> > > There are many cases where we need to expand the original code in order
> > > to generate checks. Some Ada constructs generate a non-trivial amount of
> > > code, with calls to the Ada run time library, exception handlers etc.
> > > Once we expand such code, it is unlikely it could be optimized away.
> > > I agree with Richard that we need optimize away such constructs as early
> > > as possible, which is in the front end before expansion.
> >
> > Instead of emitting runtime calls, would it be possible to emit tree
> > codes with well defined semantics?  On finding them, the optimizers
> > would know that it's not just an arbitrary function call for instance
> > (perhaps adding attributes to the libcall).
> >
> 
> Not in most cases. The runtime environment in Ada provides about everything 
> you'd expect from a real-time operating system.
> 
Well, I know nothing about Ada so I'm not sure what you mean by that
remark.  That's why I was asking for specific examples.  Annotated, if
possible.


Thanks.  Diego.

Re: [RFC] Contributing tree-ssa to mainline

[Tom Tromey]

>>>>> "Richard" == Richard Kenner <kenner@vlsi1.ultra.nyu.edu> writes:

>     Even if tree-SSA didn't made important speedups for common C programs I
>     think this is not problem as long as it is not making C worse and do
>     make C++ and Java better.

Richard> Can similar cases as those shown for C++ be constructed and
Richard> measured for Java?

I wouldn't expect to find Java equivalents of the C++ abstraction
penalty tests, since Java doesn't have stack-allocated objects.  (My
understanding is that we improve on these tests due to being able to
split up and register-ize stack-allocated objects...)

Right now I think the tree-ssa benefits to Java are more potential
than actual.  In the future we hope to get array bounds check
elimination, elimination of redundant type checks, and perhaps
elimination of redundant class initialization.

Tom

Re: [RFC] Contributing tree-ssa to mainline

[Dan Nicolaescu]

kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes:

  > Instead, I think the tree-ssa folks should implement several new
  > optimizers that rely on higher-level information to show the utility of the
  > new infrastucture and should produce test cases (preferably in C) that
  > show the success of those optimizers.  I think that's both an easier and
  > more relevant standard.

Here one such example, a testcase from the testsuite that works
due to the SRA implementation. This is just one example, probably
more can be constructed easily.

http://gcc.gnu.org/cgi-bin/cvsweb.cgi/~checkout~/gcc/gcc/testsuite/gcc.dg/tree-ssa/Attic/sra-1.c?rev=1.1.2.1&content-type=text/plain&only_with_tag=tree-ssa-20020619-branch

All the tests in the above file pass on the tree-ssa branch.
At most 2 of the tests pass on any of the following compilers:
Intel-8.0, PGI-5.0-2, SUN Forte-7, MS-VisualC-6, DEC cc and HPPA cc
(whatever versions are installed on testdrive.hp.com). 

Re: [RFC] Contributing tree-ssa to mainline

[Diego Novillo]

On Mon, 2004-01-19 at 12:46, law@redhat.com wrote:

> FWIW, the plan is to use the CCP engine for global value range propagation
> (and other stuff like global null pointer check elimination).  The biggest
> blocker is simply time to generalize the existing CCP code so that it can
> do something other than propagate simple constants.  Using a CCP engine
> for these optimizations is well understood technology.
> 
It's next in my TODO list, so it will certainly be available RSN.


Diego.

Re: [RFC] Contributing tree-ssa to mainline

[John R. Shannon]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 19 January 2004 10:51 am, Diego Novillo wrote:
> On Mon, 2004-01-19 at 12:42, Geert Bosch wrote:
> > There are many cases where we need to expand the original code in order
> > to generate checks. Some Ada constructs generate a non-trivial amount of
> > code, with calls to the Ada run time library, exception handlers etc.
> > Once we expand such code, it is unlikely it could be optimized away.
> > I agree with Richard that we need optimize away such constructs as early
> > as possible, which is in the front end before expansion.
>
> Instead of emitting runtime calls, would it be possible to emit tree
> codes with well defined semantics?  On finding them, the optimizers
> would know that it's not just an arbitrary function call for instance
> (perhaps adding attributes to the libcall).
>

Not in most cases. The runtime environment in Ada provides about everything 
you'd expect from a real-time operating system.

- -- 

John R. Shannon
john@johnrshannon.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (NetBSD)

iEYEARECAAYFAkAMGjQACgkQOKbCxya4HYvPNACcCiS8F8jmy2Dpv8v/Bqc0dUa2
br0AoJnN5r3SjydYLxf79DmbRX1hwuj9
=dw6c
-----END PGP SIGNATURE-----

Re: [RFC] Contributing tree-ssa to mainline

[Diego Novillo]

On Mon, 2004-01-19 at 12:42, Geert Bosch wrote:

> There are many cases where we need to expand the original code in order
> to generate checks. Some Ada constructs generate a non-trivial amount of
> code, with calls to the Ada run time library, exception handlers etc.
> Once we expand such code, it is unlikely it could be optimized away.
> I agree with Richard that we need optimize away such constructs as early
> as possible, which is in the front end before expansion.
> 
Instead of emitting runtime calls, would it be possible to emit tree
codes with well defined semantics?  On finding them, the optimizers
would know that it's not just an arbitrary function call for instance
(perhaps adding attributes to the libcall).

But I'm oversimplifying.  We would have to talk about specific cases.


Diego.

Re: [RFC] Contributing tree-ssa to mainline

[law]

In message <400C142A.6010205@gnat.com>, Robert Dewar writes:
 >>  >However Ada is not the only language having checks.  In some extend,
 >>  >Java has the array bounds too.  If the value range propagation pass were
 >>  >available, Java would take benefit of it too.
 >> And C/C++ when instrumented to detect invalid memory operations.
 >> 
 >> jeff
 >
 >Certainly Ada would benefit from such a pass. Right now, the front end
 >of Ada does a lot of work on computing value ranges, but it does a poor
 >job of propagation, since we have not put any kind of non-trivial flow
 >graph propagation into the front end.
FWIW, the plan is to use the CCP engine for global value range propagation
(and other stuff like global null pointer check elimination).  The biggest
blocker is simply time to generalize the existing CCP code so that it can
do something other than propagate simple constants.  Using a CCP engine
for these optimizations is well understood technology.

jeff

Re: [RFC] Contributing tree-ssa to mainline

[Geert Bosch]

On Jan 19, 2004, at 07:48, Diego Novillo wrote:
> On Mon, 2004-01-19 at 07:26, Richard Kenner wrote:
>> A case I know about in Ada is check elimination.  Because the default 
>> for Ada
>> is enabling checking, it's quite important to eliminate checks that 
>> can be
>> proven not to fail.  Theoretically, a lot this could be 
>> language-independent
>> optimizers by value range propagation and related optimizations.  But 
>> the
>> front-end can do a much better job because it has information only it 
>> knows.
>>
> Such as?  Full FE type information is available in GIMPLE.  VRP is one
> of the passes I'm planning to work on in the immediate future.  The 
> goal
> is to eliminate mudflap checks, though it should help Java and Ada as
> well.

There are many cases where we need to expand the original code in order
to generate checks. Some Ada constructs generate a non-trivial amount of
code, with calls to the Ada run time library, exception handlers etc.
Once we expand such code, it is unlikely it could be optimized away.
I agree with Richard that we need optimize away such constructs as early
as possible, which is in the front end before expansion.

   -Geert

Re: [RFC] Contributing tree-ssa to mainline

[Robert Dewar]

>  >However Ada is not the only language having checks.  In some extend,
>  >Java has the array bounds too.  If the value range propagation pass were
>  >available, Java would take benefit of it too.
> And C/C++ when instrumented to detect invalid memory operations.
> 
> jeff

Certainly Ada would benefit from such a pass. Right now, the front end
of Ada does a lot of work on computing value ranges, but it does a poor
job of propagation, since we have not put any kind of non-trivial flow
graph propagation into the front end.

Re: [RFC] Contributing tree-ssa to mainline

[law]

In message <20040117171753.36031.qmail@web41106.mail.yahoo.com>, Dara Hazeghi w
rites:
 >1) A committment by people to fix regressions/bugs as
 >they appear, as opposed to right at the end of the
 >release cycle. Until a month ago, there were only
 >really 3 or 4 people actively fixing regressions on
 >mainline which is partly the reason branching for 3.4
 >has been so slow.
Red Hat's plan is to move to a tree-ssa based compiler as soon as it is
feasible to do so (and IMHO it is not feasible at this time).  We believe
that the tree-ssa infrastructure and the optimizations built around it are
critical to the long term relevance of GCC, particularly in the face of
customer demands for free development tools that compare more favorably
with the vendor tools.

With that in mind, I don't see any problem making a commitment for Red Hat
to addressing regressions, bugs and documentation issues -- simply because
it is in Red Hat's best interest to address those issues.

It has always been our assumption that such issues would initially fall
largely upon the shoulders of the tree-ssa team as the rest of the GCC
development community ramps up on the new infrastructure.

 >2) A general consensus that the mainline won't simply
 >be abandoned once the changes get merged in. With
 >new-ra for instance, we now have 2 register
 >allocators, and it doesn't seem like we can get rid of
 >either in the forseeable future (wasn't there a plan
 >to switch fully to new-ra at some point?).
In the immediate term, Red Hat's focus is on 3.4 and tree-ssa.  Mainline
will probably not be a focus for Red Hat's development efforts until such
time as tree-ssa is merged.

Jeff

Re: [RFC] Contributing tree-ssa to mainline

[Richard Kenner]

    But I wouldn't suggest tracking dataflow in the front-end solely for
    the case of optimization purpose, particularly for things like bounds
    checking since we really need to be doing that in language independent
    ways given that every language can and should be making use of those
    optimizers.

We mostly agree, but I maintain that there will always be some
language-dependent optimizations that need to be done in the front end that
will use such information.

For example, there are numerous cases in Ada where the presence of a certain
construct within a block means the block has to be "wrapped" in some way.
Whether that happens may depend on whether some bounds are variable or
constant or whether or not the construct in question is in dead code or not.

It can be very hard to express to language-independent parts of the compiler
what to "undo" and under what conditions (the variable vs. constant bound
information for some types of data structures are a good example here).

Adding relatively simple constant-propagation code to the front end caught a
lot of these cases and was therefore a worthwhile thing to do, despite
possible duplication with later passes.  Simple static value range
determination code is another example as is simple dead-code elimination.

Then there's the point that Robert made: you often want to give warnings for
dead code or unused variables and the more language-specific those warning
are, the more use they'll be to the programmer.

Re: [RFC] Contributing tree-ssa to mainline

[law]

In message <10401191507.AA28782@vlsi1.ultra.nyu.edu>, Richard Kenner writes:
 >Not necessarily.  If the front end is already tracking some dataflow for its
 >own purposes and can use that knowlege to eliminate a check, why would it be
 >better for it *not* to do so?  As I said, all over GCC we're doing
 >"duplicate" simplifications and the fact that we do so is one of the major
 >strengths of the compiler.
Certainly if you have information handy which allows you to create more
efficient code, then by all means use it.  But I wouldn't suggest tracking
dataflow in the front-end solely for the case of optimization purpose,
particularly for things like bounds checking since we really need to be
doing that in language independent ways given that every language can and
should be making use of those optimizers.


 >    There has been some discussion of perhaps lowering ARRAY_REFs.  But
 >    that would be done relatively late in the tree pipeline.
 >
 >Good, because that's my concern: the form of the subscript information is
 >critical to many high-level loop optimizations.  If you're going to have to
 >figure that out from an address computation, you're giving up much of the
 >benefit of doing that optimization on trees instead of RTL>
Agreed.   

jeff

Re: [RFC] Contributing tree-ssa to mainline

[law]

In message <20040119125145.GH31365@atrey.karlin.mff.cuni.cz>, Jan Hubicka write
s:
 >However Ada is not the only language having checks.  In some extend,
 >Java has the array bounds too.  If the value range propagation pass were
 >available, Java would take benefit of it too.
And C/C++ when instrumented to detect invalid memory operations.

jeff

Re: [RFC] Contributing tree-ssa to mainline

[Richard Kenner]

    > The Ada tree has *a lot* more information than can be (or should be)
    > encoded into the GCC tree datastructure.  Each tree node has 183
    > defined flags, for example.

    When the time comes to generate GENERIC from Ada, then that
    information should be propagated down.  

I disagree.  I see no reason to find ways of representing the sort of
language-specific information that's encoded there.  Sure, some of that is
used for code generation information and is propagated down, but most of it
is not and need not be.  If you're curious about what kinds of information is
in Ada tree nodes, look at ada/einfo.ads and ada/sinfo.ads.  Note that the
Ada tree is a parse tree augmented with semantic information, rather than a
purely semantic tree like GCC.

    One thing that I'm vaguely concerned regarding Ada is the potential of
    having to create new GIMPLE trees.  Having to create new GENERIC codes
    wouldn't be a problem, but adding GIMPLE means changing the optimizers
    as well.

I don't know enough about GIMPLE to answer that and I think it's not
practical to answer that for certain at least until "old-style"
function-at-a-time is working for Ada, but as long as there's handling for
the present PLACEHOLDER_EXPR and WITH_RECORD_EXPR, which seems to me to be
needed at that level (though perhaps it might not be), I doubt there should
be any significant issue here.

    I only meant checks that need dataflow information.  If the
    elimination needs dataflow information, then the FE will be
    duplicating code and effort.

Not necessarily.  If the front end is already tracking some dataflow for its
own purposes and can use that knowlege to eliminate a check, why would it be
better for it *not* to do so?  As I said, all over GCC we're doing
"duplicate" simplifications and the fact that we do so is one of the major
strengths of the compiler.

    There has been some discussion of perhaps lowering ARRAY_REFs.  But
    that would be done relatively late in the tree pipeline.

Good, because that's my concern: the form of the subscript information is
critical to many high-level loop optimizations.  If you're going to have to
figure that out from an address computation, you're giving up much of the
benefit of doing that optimization on trees instead of RTL>

Re: [RFC] Contributing tree-ssa to mainline

[Lars Segerlund]

 I agree with Richard, there is no problem, if the Ada compiler won't run with tree-ssa then the ada people have to run 3.4 ....

 / Lars Segerlund.


On Fri, 16 Jan 04 21:41:36 EST
kenner@vlsi1.ultra.nyu.edu (Richard Kenner) wrote:

>     > As it is today, it is impossible to build an Ada compiler with the
>     > branch.
> 
>     I'm afraid that's a blocker.
> 
> I disagree.  If every other criteria is met, I don't see that as a blocking
> issue, mostly because that's not a "fault" of the tree-ssa project and it
> would be unfair to hold them up while that work is being done.
> 
> At some point in the not too distant future, the Ada front end will handle
> function-at-a-time and then converting it to using tree-ssa might be
> something that the tree-ssa folks can either do or help with, but I don't see
> this is a major timing issue: even if we had one release of GCC (say 3.5)
> that didn't support Ada, it wouldn't be fatal and should not hold up tree-ssa
> if it were ready before the Ada conversion was done.

Re: [RFC] Contributing tree-ssa to mainline

[Diego Novillo]

On Mon, 2004-01-19 at 09:19, Richard Kenner wrote:
>     Full FE type information is available in GIMPLE.  
> 
> The Ada tree has *a lot* more information than can be (or should be)
> encoded into the GCC tree datastructure.  Each tree node has 183 defined
> flags, for example.
> 
OK.  When the time comes to generate GENERIC from Ada, then that
information should be propagated down.  One thing that I'm vaguely
concerned regarding Ada is the potential of having to create new GIMPLE
trees.  Having to create new GENERIC codes wouldn't be a problem, but
adding GIMPLE means changing the optimizers as well.  We'll see.

> I don't follow.  Why "had better not"?  For every check that the FE
> can eliminate, there's that much less work for the rest of the
> compiler to do.
>
I only meant checks that need dataflow information.  If the elimination
needs dataflow information, then the FE will be duplicating code and
effort.  If no dataflow info is needed, then by all means, remove away.


> Instead, I think the tree-ssa folks should implement several new
> optimizers that rely on higher-level information to show the utility of the
> new infrastucture and should produce test cases (preferably in C) that
> show the success of those optimizers.  I think that's both an easier and
> more relevant standard.
> 
We have done several already.  Since you seem interested, please:

     1. Visit http://gcc.gnu.org/projects/tree-ssa/
     2. Get the branch or the daily binary snapshots and try it out.
     3. Read the source code.


>     What information?  Type?  Yes, we preserve full user-level type and
>     variable information.  Control flow?  We have a flow graph.  Data
>     flow?  We have an SSA web.  What specific information are you
>     concerned about?
> 
> Information regarding the form of array and component accesses.  In a
> discussion about RTL loop code, I thought I saw that the addressing computation
> would be done early on and the COMPONENT_REFs and ARRAY_REFs would be removed.
>
No.  COMPONENT_REFs and ARRAY_REFs are kept (though we need to address
cases where the C FE is generating pointer dereferences instead of
ARRAY_REFs).

There has been some discussion of perhaps lowering ARRAY_REFs.  But that
would be done relatively late in the tree pipeline.


Diego.

Re: [RFC] Contributing tree-ssa to mainline

[Robert Dewar]

Richard Kenner wrote:

> I agree that *re-doing* is not a good design decision, but it's quite often
> the case that *doing* optimizations in a front-end is the appropriate design
> decision.

Another issue is that optimizations often go along with useful warnings,
and often it is the case that these warnings are best stated in highly
language specific terms.

Re: [RFC] Contributing tree-ssa to mainline

[Richard Kenner]

    Full FE type information is available in GIMPLE.  

The Ada tree has *a lot* more information than can be (or should be)
encoded into the GCC tree datastructure.  Each tree node has 183 defined
flags, for example.

    VRP is one of the passes I'm planning to work on in the immediate
    future.  The goal is to eliminate mudflap checks, though it should
    help Java and Ada as well.

Sure it will.  There will indeed be checks that can't be supressed statically
that can with VRP, but the opposite is also true.

    If the check needs dataflow information to be eliminated, the FE had
    better not deal with it.

I don't follow.  Why "had better not"?  For every check that the FE
can eliminate, there's that much less work for the rest of the
compiler to do.  A check is merely a flag on an operation node in the
Ada tree.  If it can be suppressed at that level, we avoid ever generating
*any* tree nodes for the check.  That seems a good thing to me: why do you
see it as something that "had better not" happen?

    Nothing in tree-ssa is language specific.

I didn't say there was.  What I said was that it looked like the *example*
was relying on language-specific features.  It turned out I misread the
message, but my concern was in the example only.

    I have an idea.  Why don't you provide test cases in the form of
    bugzilla reports? 

Because I don't exactly what the optimizations goals are, nor am I
particularly concerned about the details.

    Even more, we could vote on a set of specific bugzilla PRs as merge or
    post-merge criteria.  

I think that would be unfair to the tree-ssa project.  I don't see the merge
criteria as the GCC project giving some test cases to the tree-ssa folks and
saying "show me that you can improve these cases".  I think that's much too
hard a standard to meet.

Instead, I think the tree-ssa folks should implement several new
optimizers that rely on higher-level information to show the utility of the
new infrastucture and should produce test cases (preferably in C) that
show the success of those optimizers.  I think that's both an easier and
more relevant standard.

    What information?  Type?  Yes, we preserve full user-level type and
    variable information.  Control flow?  We have a flow graph.  Data
    flow?  We have an SSA web.  What specific information are you
    concerned about?

Information regarding the form of array and component accesses.  In a
discussion about RTL loop code, I thought I saw that the addressing computation
would be done early on and the COMPONENT_REFs and ARRAY_REFs would be removed.

Re: [RFC] Contributing tree-ssa to mainline

[Richard Kenner]

    On the other hand, if Ada can really do the job of its check
    elimination so much better than a generic optimizer, fair enough.  But
    range check elimination using VRP is a sufficiently generic problem
    that many languages will benefit.

I agree.  I wasn't arguing against VRP or saying that it would not be useful
in eliminating range checks, just that there are language-specific tests that
can more easily be done in the front end that eliminate the need for
sophisticated optimizations like that.

The GCC approach has always been to do as many optimizations as possible at
all levels: we do constant folding at both the tree and RTL level.  This is
done not just to avoid the risk of missing an opportunity, but because the
earlier we do an optimization, the less work the lower level optimizers have
to do and that improves compilation speed.

I see it as the same with checks and VRP: certainly VRP ought to be
implemented and certainly it will eliminate some checks, but that does *not*
mean we shouldn't implement a check-elimination pass in the Ada front end
that uses static semantic information that language-independent code doesn't
have access to.  The reasons are the same as above: not only does it avoid
the risk of missing an opportunity, but it creates less work for subsequent
passes to do.

    And of course there are other things: escape analysis, for example.
    Sure, I could do that in the Java front end, but I'd rather not.

I don't know enough about escape analysis in Java to offer any opinion as to
whether it's appropriate to have such in the front end, but I believe that if
it's easier to do at that level, it should be done there even if other
optimizers could also catch some cases.

A lot of the strategy for Ada was not be concerned about generating a lot of
code and to assume that GCC would optimize all the junk away. This strategy
has worked remarkably well, but does cause worse code in many more cases than
we'd like to see due to some notable failures in language-independent
optimization not being able to optimize some cases.  There's reason to
believe tree-ssa will do a better job, but the best job would be produced by
not generating the junk in the first place.

I believe the reason for GCC's great success in the past has been its
strategy of doing optimizations at all possible levels and I also believe
this will be reason for its success in the future.  So I see tree-ssa as an
another set of optimizers, but not one that will remove the need for having
any optimizations in the front end nor certainly remove the need for RTL
optimizers.  I don't think this is or should be a goal of the tree-ssa project.

Re: [RFC] Contributing tree-ssa to mainline

[Theodore Papadopoulo]

kenner@vlsi1.ultra.nyu.edu said:
> A case I know about in Ada is check elimination.  Because the default
> for Ada is enabling checking, it's quite important to eliminate checks
> that can be proven not to fail.  Theoretically, a lot this could be
> language-independent optimizers by value range propagation and related
> optimizations.  But the front-end can do a much better job because it
> has information only it knows. Moreover, by suppressing the check
> before generating any code for it, compilation time is reduced.  I
> think this is clearly the proper place for that optimization.

AFAIK, tree-ssa would be beneficial in this situation. By making the 
check elimination work on GIMPLE (I hope it is the proper place), 
this would remove this from the ADA front-end and generalize to other 
languages. I assume that the sole introduction of optimization on 
trees allow you to move some code out of the front-end to the tree 
optimization passes of tree-ssa.

That being said, as an exterior observer, what I can say is that we 
have seen quite a few major contributors switching to tree-ssa recently...
This is surely partially because gcc-3.4 was in stage 3, but the move 
has been more marked than for previous releases 
IMHO.

Having the work-forces (rougthly) splitted in two is not a good thing IMO.
That should be considered...


--------------------------------------------------------------------
Theodore Papadopoulo
Email: Theodore.Papadopoulo@sophia.inria.fr Tel: (33) 04 92 38 76 01
 --------------------------------------------------------------------

Re: [RFC] Contributing tree-ssa to mainline

[Jan Hubicka]

>     Even if tree-SSA didn't made important speedups for common C programs I
>     think this is not problem as long as it is not making C worse and do
>     make C++ and Java better.
> 
> Can similar cases as those shown for C++ be constructed and measured for Java?
> 
>     I don't think re-doing optimizations in each frontend is good design
>     decision.
> 
> I agree that *re-doing* is not a good design decision, but it's quite often
> the case that *doing* optimizations in a front-end is the appropriate design
> decision.
> 
> A case I know about in Ada is check elimination.  Because the default for Ada
> is enabling checking, it's quite important to eliminate checks that can be
> proven not to fail.  Theoretically, a lot this could be language-independent
> optimizers by value range propagation and related optimizations.  But the
> front-end can do a much better job because it has information only it knows.
> Moreover, by suppressing the check before generating any code for it,
> compilation time is reduced.  I think this is clearly the proper place for
> that optimization.

However Ada is not the only language having checks.  In some extend,
Java has the array bounds too.  If the value range propagation pass were
available, Java would take benefit of it too.

In the ideal world, where both Java and Ada used GCC trees for
intermediate representation and gimple based optimizers were ready, the
expenses for expanding bounds checking into gimple form would be much
lower and thus it may be viable to implement gimple based value range
pass that would elliminate need to do the same in Ada and Java with no
(or very little) performance cost brought by abstraction.

For me, major benefit of tree-SSA is to design such interfaces so both
frontends and optimizers may benefit from this.
But this definitly belongs to the hypotetical benefits category for you.
> 
> That's why I asked about this, if it's truly C++-specific: wouldn't it be
> better in the C++ front end?  That's why it's important to understand how
> language-independent it is.

No, it is not language dependent, it is about generic highlever
optimizations.  There definitly are C, C++ and Java testcases.

I just wanted to point out that it is easier to find real world
testcases for C++, than C and that I believe if there were just C++/Java
testcases, it would be enought to qualify the change.
> 
> I'd like to see examples of some of these optimizations that provide
> "significant" (leaving that undefined for the moment) benefits for all
> languages before accepting that the tree-ssa structure is as beneficial as
> its proponents argue.
> 
> One specific concern I have is the issue of when to lower.  I admit I haven't
> been following the project closely, so please feel free to correct me if I'm
> wrong, but my sense is that lowering of the level of the tree is now being
> done very *early*.  That seems to me to be potentially incompatible with the
> argument that doing such things as loop optimization at the tree level can
> use higher-level information: are we preserving such information?

The trees are lowered early, but the main idea is that the lower
form preserve all the information relevant to optimizers.  This is
unlike RTL where we lose good part of type information and for instance
semantic on overflow.
The lowering can be seen as kind of bringing trees into more regular
form so they are easier to optimize, not throwing away high level
details for benefit of target specific details as done on RTL level.

Honza
> 
> As I said, perhaps I misunderstand what's going on, but if I don't, I think
> the above is the critical issue and the design space of when to lower needs
> to be resolved by actually demonstrating some of the hoped-for high-level
> optimizations. I would not be comfortable merging tree-ssa until that level
> of design issues have been settled.

Re: [RFC] Contributing tree-ssa to mainline

[Diego Novillo]

On Mon, 2004-01-19 at 07:26, Richard Kenner wrote:

> A case I know about in Ada is check elimination.  Because the default for Ada
> is enabling checking, it's quite important to eliminate checks that can be
> proven not to fail.  Theoretically, a lot this could be language-independent
> optimizers by value range propagation and related optimizations.  But the
> front-end can do a much better job because it has information only it knows.
>
Such as?  Full FE type information is available in GIMPLE.  VRP is one
of the passes I'm planning to work on in the immediate future.  The goal
is to eliminate mudflap checks, though it should help Java and Ada as
well.

> Moreover, by suppressing the check before generating any code for it,
> compilation time is reduced.  I think this is clearly the proper place for
> that optimization.
> 
If the check needs dataflow information to be eliminated, the FE had
better not deal with it.


> That's why I asked about this, if it's truly C++-specific: wouldn't it be
> better in the C++ front end?  That's why it's important to understand how
> language-independent it is.
> 
Nothing in tree-ssa is language specific.  There's quite a bit of design
documentation available in the project's page.  The presentations last
year at GCC Summit should be useful.  And you can always check the
branch out and check for yourself.


> However, I'm not as willing as some people to simply accept the argument that
> this will lead to "considerable benefits" due to what are essentially
> theoretical arguments.  I'm a pragmatist: I'd like to *see* those benefits.
> 
I have an idea.  Why don't you provide test cases in the form of
bugzilla reports?  We have some reports that point out specific
performance problems that we have been addressing all along.  Merge or
no merge, those test cases will help fix the more noticeable problems. 
Particularly if they are representative samples of popular constructs.

Even more, we could vote on a set of specific bugzilla PRs as merge or
post-merge criteria.  I am going to be creating some PRs for the
specific issues that were raised in the thread regarding documentation,
for instance.


> One specific concern I have is the issue of when to lower.  I admit I haven't
> been following the project closely, so please feel free to correct me if I'm
> wrong, but my sense is that lowering of the level of the tree is now being
> done very *early*.  That seems to me to be potentially incompatible with the
> argument that doing such things as loop optimization at the tree level can
> use higher-level information: are we preserving such information?
> 
What information?  Type?  Yes, we preserve full user-level type and
variable information.  Control flow?  We have a flow graph.  Data flow? 
We have an SSA web.  What specific information are you concerned about?

> As I said, perhaps I misunderstand what's going on, but if I don't, I think
> the above is the critical issue and the design space of when to lower needs
> to be resolved by actually demonstrating some of the hoped-for high-level
> optimizations. I would not be comfortable merging tree-ssa until that level
> of design issues have been settled.
>
I really think you ought to take a look at the branch before we can
address your concerns.  You are being woefully vague.


Diego.

Re: [RFC] Contributing tree-ssa to mainline

[Paul Brook]

On Monday 19 January 2004 12:36 pm, Paul Brook wrote:
> Admittedly -fbounds-check is turned on by default in fortran, but neither
> is -O2.

This should be "turned off by default", obviously.

Paul

Re: [RFC] Contributing tree-ssa to mainline

[Andrew Haley]

Richard Kenner writes:
 > 
 > A case I know about in Ada is check elimination.  Because the
 > default for Ada is enabling checking, it's quite important to
 > eliminate checks that can be proven not to fail.  Theoretically, a
 > lot this could be language-independent optimizers by value range
 > propagation and related optimizations.  But the front-end can do a
 > much better job because it has information only it knows.
 > Moreover, by suppressing the check before generating any code for
 > it, compilation time is reduced.  I think this is clearly the
 > proper place for that optimization.

I would reject this approach on the grounds of parsimony: Java needs
to generate (and remove) these checks as well, and if we do
optimization in the front end we'll have multiple optimizers
essentially doing the same thing, probably using the same algorithms.
We'll have separate implementations of the same algorithms -- with
disjoint sets of errors.

On the other hand, if Ada can really do the job of its check
elimination so much better than a generic optimizer, fair enough.  But
range check elimination using VRP is a sufficiently generic problem
that many languages will benefit.

And of course there are other things: escape analysis, for example.
Sure, I could do that in the Java front end, but I'd rather not.

Andrew.

Re: [RFC] Contributing tree-ssa to mainline

[Paul Brook]

On Monday 19 January 2004 12:26 pm, Richard Kenner wrote:
> A case I know about in Ada is check elimination.  Because the default for
> Ada is enabling checking, it's quite important to eliminate checks that can
> be proven not to fail.  Theoretically, a lot this could be
> language-independent optimizers by value range propagation and related
> optimizations.  But the front-end can do a much better job because it has
> information only it knows. Moreover, by suppressing the check before
> generating any code for it, compilation time is reduced.  I think this is
> clearly the proper place for that optimization.

I don't know what form of checking is performed in Ada, but optimizations to 
remove array bound checks would also be useful for fortran. Particularly 
Fortran90 where it is much more common to know the shape of an array.

Admittedly -fbounds-check is turned on by default in fortran, but neither is 
-O2.

Paul

Re: [RFC] Contributing tree-ssa to mainline

[Andrew Haley]

Re: [RFC] Contributing tree-ssa to mainline

[Richard Kenner]

    Did you not read my message?  The test I gave *was* C.

I read it, but obviously not carefully enough!

I knew the original code in that PR was C++ and then saw your C++ comment
in the last paragraph and missed the point that you'd used the C version
in that PR.

I stand corrected.

Re: [RFC] Contributing tree-ssa to mainline

[Richard Kenner]

    Even if tree-SSA didn't made important speedups for common C programs I
    think this is not problem as long as it is not making C worse and do
    make C++ and Java better.

Can similar cases as those shown for C++ be constructed and measured for Java?

    I don't think re-doing optimizations in each frontend is good design
    decision.

I agree that *re-doing* is not a good design decision, but it's quite often
the case that *doing* optimizations in a front-end is the appropriate design
decision.

A case I know about in Ada is check elimination.  Because the default for Ada
is enabling checking, it's quite important to eliminate checks that can be
proven not to fail.  Theoretically, a lot this could be language-independent
optimizers by value range propagation and related optimizations.  But the
front-end can do a much better job because it has information only it knows.
Moreover, by suppressing the check before generating any code for it,
compilation time is reduced.  I think this is clearly the proper place for
that optimization.

That's why I asked about this, if it's truly C++-specific: wouldn't it be
better in the C++ front end?  That's why it's important to understand how
language-independent it is.

    In longer run, with the new loop optimizer or profile driven inlining,
    we will see considerable benefits for C programs too, but I would
    prefer this to not be blocker for tree-SSA acceptance.

I would.

    The optimizations tree-SSA implement right now are just essentials to
    get more work in this area done.

I'm not suggesting not getting any work done: there's active development work
being on it now and I'm all in favor of it being continued.

However, I'm not as willing as some people to simply accept the argument that
this will lead to "considerable benefits" due to what are essentially
theoretical arguments.  I'm a pragmatist: I'd like to *see* those benefits.

I'd like to see examples of some of these optimizations that provide
"significant" (leaving that undefined for the moment) benefits for all
languages before accepting that the tree-ssa structure is as beneficial as
its proponents argue.

One specific concern I have is the issue of when to lower.  I admit I haven't
been following the project closely, so please feel free to correct me if I'm
wrong, but my sense is that lowering of the level of the tree is now being
done very *early*.  That seems to me to be potentially incompatible with the
argument that doing such things as loop optimization at the tree level can
use higher-level information: are we preserving such information?

As I said, perhaps I misunderstand what's going on, but if I don't, I think
the above is the critical issue and the design space of when to lower needs
to be resolved by actually demonstrating some of the hoped-for high-level
optimizations. I would not be comfortable merging tree-ssa until that level
of design issues have been settled.

Re: [RFC] Contributing tree-ssa to mainline

[Andrew Pinski]

On Jan 19, 2004, at 04:00, Jan Hubicka wrote:
>
> While it is possible to find/construct C testcases with large
> abstraction penalties, this is not as common as for C++ or other more
> modern languages.

Actually it is getting easy and easy to find C testcases with large 
abstraction penalties
with C99.
Just at a look at the bugs which are suspended as fixed on the 
tree-ssa. PR 9540 is a good
example for C.  I would have filed a bug that effects real code, code 
that is used in GNUStep
and Mac OS X and the applications build using them.

Thanks,
Andrew Pinski
bug master

Re: [RFC] Contributing tree-ssa to mainline

[Richard Henderson]

On Mon, Jan 19, 2004 at 06:47:02AM -0500, Richard Kenner wrote:
> However, it would be good to see cases of both of the above for C as well as
> C++ ...

Did you not read my message?  The test I gave *was* C.


r~

Re: [RFC] Contributing tree-ssa to mainline

[Jan Hubicka]

>     So we've missed the required factor of 2 on this test case by 0.8%.
>     Since that seems likely to be in the relm of measurement error, I
>     think that should qualify.
> 
> I agree.
> 
>     With a bit more work unwravelling C++ front-end obfuscation, I would
>     expect the 10-20% to be visible on just about any object abstraction
>     test case.  Particularly for any object that has more than one field,
>     and thus can't benefit from rtl addressof.  That seems like it should
>     be a large enough class to qualify.
> 
> Likewise.
> 
> However, it would be good to see cases of both of the above for C as well as
> C++: if the gain is just C++, one could argue that the most appropriate place
> for such code is in the C++ front end.  (There are Ada-specific optimizations
> in the Ada front end, for example.)

While it is possible to find/construct C testcases with large
abstraction penalties, this is not as common as for C++ or other more
modern languages.

Even if tree-SSA didn't made important speedups for common C programs I
think this is not problem as long as it is not making C worse and do
make C++ and Java better.  I don't think re-doing optimizations in each
frontend is good design decision.

In longer run, with the new loop optimizer or profile driven inlining,
we will see considerable benefits for C programs too, but I would
prefer this to not be blocker for tree-SSA acceptance.

The optimizations tree-SSA implement right now are just essentials to
get more work in this area done.

Honza
> 
> The tree-ssa infrastructure is supposed to benefit *all* languages.  If
> benefits can be shown in C, they will clearly apply to all languages.  But
> that's not true for C++.

Re: [RFC] Contributing tree-ssa to mainline

[Richard Kenner]

    So we've missed the required factor of 2 on this test case by 0.8%.
    Since that seems likely to be in the relm of measurement error, I
    think that should qualify.

I agree.

    With a bit more work unwravelling C++ front-end obfuscation, I would
    expect the 10-20% to be visible on just about any object abstraction
    test case.  Particularly for any object that has more than one field,
    and thus can't benefit from rtl addressof.  That seems like it should
    be a large enough class to qualify.

Likewise.

However, it would be good to see cases of both of the above for C as well as
C++: if the gain is just C++, one could argue that the most appropriate place
for such code is in the C++ front end.  (There are Ada-specific optimizations
in the Ada front end, for example.)

The tree-ssa infrastructure is supposed to benefit *all* languages.  If
benefits can be shown in C, they will clearly apply to all languages.  But
that's not true for C++.

Re: [RFC] Contributing tree-ssa to mainline

[Richard Kenner]

    Documentating isn't as fun as coding.

Which is one of the reasons why good software engineering practice says to
write documentation *before* the code.

Re: [RFC] Contributing tree-ssa to mainline

[Scott A Crosby]

On Fri, 16 Jan 2004 22:09:35 -0800, Andrew Pinski <pinskia@physics.uc.edu> writes:

> >>> people claimed it was "essential" for 3.5 since there was a
> >>> tremendous
> >>> improvement on some C++ cases.  So let's see those cases.
> >>>
> >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12747
> >

There's also PR2399, where bar is a template based representation of a
16x16x16 array:

void bar (D3VolumeIndex<char,D3VolumeFixed<char,16,16,16> >::Index bar) {
  bar[5][4][3]=10;
}

This compiles to a function using 120 bytes of stack space and 25
mov's. It should be a single instruction.

As this would have been in the inner loops for my analysis package, I
switched idioms rather than benchmark the performance degradation. I
expect it would have been hideous, unless inlining and LCM moved the
useless initialization out of the loops.

Scott

Re: [RFC] Contributing tree-ssa to mainline

[Diego Novillo]

On Sat, 2004-01-17 at 16:32, Richard Henderson wrote:

> So we've missed the required factor of 2 on this test case by 0.8%.
> Since that seems likely to be in the relm of measurement error, I
> think that should qualify.
> 
PR12747 shows ~3x speedup on tree-ssa, as well.


Diego.

Re: [RFC] Contributing tree-ssa to mainline

[Richard Henderson]

On Sat, Jan 17, 2004 at 04:07:26AM +0100, Steven Bosscher wrote:
> On Saturday 17 January 2004 03:30, Richard Kenner wrote:
> > My feeling is that "success" would be in showing at least one class of code
> > where we see very significantly better code (at least a factor of two) and
> > we see significant (around 10-20%) performance improvement in a larger
> > class of test cases.
[...]
> Expecting tree-ssa to produce code better by a factor of two is simply
> unreasonable.

No, he's asking for one particular class of code, not all code.

Ok, here ya go -- PR 2692.  Take the (moderately large) C test case
there and attach the trivial driver:

	int main()
	{
	  Complex8 m[6][6];
	  volatile Complex8 sink;
	  int i;

	  memset (m, 0, sizeof (m));
	  for (i = 0; i < 1000000; i++)
	    sink = determinant(m);

	  return 0;
	}


		MAINLINE		TREE-SSA	Change
user time	4.96			2.52		50.8%
.text size	51523			28687		55.6%

So we've missed the required factor of 2 on this test case by 0.8%.
Since that seems likely to be in the relm of measurement error, I
think that should qualify.

With a bit more work unwravelling C++ front-end obfuscation, I would
expect the 10-20% to be visible on just about any object abstraction
test case.  Particularly for any object that has more than one field,
and thus can't benefit from rtl addressof.  That seems like it should
be a large enough class to qualify.


r~

Re: [RFC] Contributing tree-ssa to mainline

[Mark Mitchell]

On Sat, 2004-01-17 at 09:07, Joseph S. Myers wrote:
> On Sat, 17 Jan 2004, Daniel Berlin wrote:
> 
> > As Diego stated when SRA was committed, the following limitation exists:
> > /* Maximum number of fields that a structure should have to be 
> > scalarized.
> >     FIXME  This limit has been arbitrarily set to 5.  Experiment to find 
> > a
> >      sensible setting.  */
> > #define MAX_NFIELDS_FOR_SRA 5
> 
> Before the merge to mainline, please at least change hardcoded parameters
> like this to use --param (which does make experimenting with different
> values easier).  I've understood ever since Mark added that option
> <http://gcc.gnu.org/ml/gcc-patches/2001-02/msg00800.html> that using it
> was the convention, it just hasn't been documented as such.  OK to commit
> the following web page patch?  (The beginner.html patch is because it
> seems no-one ever took up my suggestion in that thread to add converting
> existing parameters to the projects list, and I don't think they've all
> been done.  Adding comments to parameters that for whatever reason
> shouldn't be converted to --param, saying so, would be useful.)

Yes, these patches to the docs are OK.

-- 
Mark Mitchell <mark@codesourcery.com>
CodeSourcery, LLC

Re: [RFC] Contributing tree-ssa to mainline

[Diego Novillo]

On Sat, 2004-01-17 at 08:31, Richard Kenner wrote:
>     If we are to wait for all the possible optimizations (vectorization,
>     memory hierarchy, loop transformations, etc) to be contributed, we may
>     have to wait quite a bit longer than if we included the infrastructure
>     in mainline.
> 
> My threshold wouldn't be "all possible optimizations", but enough of
> them to show that the new infrastructure not only is going to meet its
> expectations but that it isn't going to need to continue to evolve in
> major ways.
> 
Fair enough.  You bring up a good point about stability in the
infrastructure.  I do not think that we will see any major changes now. 
Perhaps transparent changes that largely don't affect major interfaces. 
> To me, merely saying that "this is obviously a better approach since
> it's more modern and is what the textbooks show" would be a *disadvantage*
> of the approach.  We need to see evidence that this approach really is better.
> 
We've shown some in this thread.  When the discussion dies down, I will
follow up with a summary so that we can hopefully make a decision at
that point.  If there's anything in particular you would be interested
to see, please let me know.


Thanks.  Diego.

Re: [RFC] Contributing tree-ssa to mainline

[Daniel Berlin]

> Absolutely.  These are the kinds of basic cleanup activities I had in
> mind when I requested peer review and suggested a way of breaking up 
> the
> changes.
>

These are just cleanups that are required before merging to the 
mainline.
I still don't think trying to break up all of tree-ssa and it's 
individual passes and submitting them makes any sense at all.

Unless we are talking about peer review simply for cleanups, and not 
for design issues.
In which case it's a matter of us looking through it ourselves for 
cleanups and whatnot we missed and pointing them out to each other.

I'd seriously rather not go about rehashing the design tradeoffs.

>
> Thanks.  Diego.
>

Re: [RFC] Contributing tree-ssa to mainline

[Dara Hazeghi]

Hello,

IMHO, releasing a compiler (3.5?) with full
integration of tree-ssa branch would be a lot more
palatable if we had:

1) A committment by people to fix regressions/bugs as
they appear, as opposed to right at the end of the
release cycle. Until a month ago, there were only
really 3 or 4 people actively fixing regressions on
mainline which is partly the reason branching for 3.4
has been so slow.

2) A general consensus that the mainline won't simply
be abandoned once the changes get merged in. With
new-ra for instance, we now have 2 register
allocators, and it doesn't seem like we can get rid of
either in the forseeable future (wasn't there a plan
to switch fully to new-ra at some point?).

3) I don't see a particularly hurry in merging. 3.4
looks to be the most exciting GCC release in quite a
while (PCH, new C++ parser, unit-at-a-time,
improvements in PGO...), and it would be a pity if
merging diverted resources away from it.

My 2 cents (from the perspective of observer and
occasional user),

Dara

__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus

Re: [RFC] Contributing tree-ssa to mainline

[Diego Novillo]

On Sat, 2004-01-17 at 12:07, Joseph S. Myers wrote:
> On Sat, 17 Jan 2004, Daniel Berlin wrote:
> 
> > As Diego stated when SRA was committed, the following limitation exists:
> > /* Maximum number of fields that a structure should have to be 
> > scalarized.
> >     FIXME  This limit has been arbitrarily set to 5.  Experiment to find 
> > a
> >      sensible setting.  */
> > #define MAX_NFIELDS_FOR_SRA 5
> 
> Before the merge to mainline, please at least change hardcoded parameters
> like this to use --param (which does make experimenting with different
> values easier).
>
Absolutely.  These are the kinds of basic cleanup activities I had in
mind when I requested peer review and suggested a way of breaking up the
changes.


Thanks.  Diego.

Re: [RFC] Contributing tree-ssa to mainline

[Joseph S. Myers]

On Sat, 17 Jan 2004, Daniel Berlin wrote:

> As Diego stated when SRA was committed, the following limitation exists:
> /* Maximum number of fields that a structure should have to be 
> scalarized.
>     FIXME  This limit has been arbitrarily set to 5.  Experiment to find 
> a
>      sensible setting.  */
> #define MAX_NFIELDS_FOR_SRA 5

Before the merge to mainline, please at least change hardcoded parameters
like this to use --param (which does make experimenting with different
values easier).  I've understood ever since Mark added that option
<http://gcc.gnu.org/ml/gcc-patches/2001-02/msg00800.html> that using it
was the convention, it just hasn't been documented as such.  OK to commit
the following web page patch?  (The beginner.html patch is because it
seems no-one ever took up my suggestion in that thread to add converting
existing parameters to the projects list, and I don't think they've all
been done.  Adding comments to parameters that for whatever reason
shouldn't be converted to --param, saying so, would be useful.)

Index: codingconventions.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/codingconventions.html,v
retrieving revision 1.30
diff -u -r1.30 codingconventions.html
--- codingconventions.html	11 Oct 2003 14:02:53 -0000	1.30
+++ codingconventions.html	17 Jan 2004 17:00:49 -0000
@@ -23,7 +23,8 @@
 
 <ul>
 
-  <li>All command-line options must be documented in the GCC manual.</li>
+  <li>All command-line options (including all <code>--param</code>
+  arguments) must be documented in the GCC manual.</li>
 
   <li>Any change to documented behavior (for example, the behavior of
   a command-line option or a GNU language extension) must include the
@@ -184,6 +185,9 @@
 against <code>error_mark_node</code> rather than by comparing the
 <code>TREE_CODE</code> against <code>ERROR_MARK</code>; see <a
 href="http://gcc.gnu.org/ml/gcc-patches/2000-10/msg00792.html">message</a>.</p>
+
+<p>Internal numeric parameters that may affect generated code should
+be controlled by <code>--param</code> rather than being hardcoded.</p>
 
 
 <h2>Spelling, terminology and markup</h2>
Index: projects/beginner.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/projects/beginner.html,v
retrieving revision 1.43
diff -u -r1.43 beginner.html
--- projects/beginner.html	3 Jan 2004 19:15:42 -0000	1.43
+++ projects/beginner.html	17 Jan 2004 17:00:49 -0000
@@ -414,6 +414,10 @@
 href="../codingconventions.html">GCC coding conventions</a>
 consistently.</li>
 
+<li>Change code to follow the coding conventions in other ways.  For
+example, change arbitrary hardcoded parameters to use the
+<code>--param</code> mechanism.</li>
+
 </ul>
 
 <h2>Port cleanliness</h2>

-- 
Joseph S. Myers
jsm@polyomino.org.uk

Re: [RFC] Contributing tree-ssa to mainline

[Gerald Pfeifer]

On Fri, 16 Jan 2004, Richard Kenner wrote:
>> I'm afraid that's a blocker.
> I disagree.

On Fri, 16 Jan 2004, Robert Dewar wrote:
> I entirely agree with Richard's assessment here.

Well, in that case forget my comment. :-)

Diego, one issue less to care about for you. :-)

Gerald

Re: [RFC] Contributing tree-ssa to mainline

[Andreas Jaeger]

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

Steven Bosscher <s.bosscher@student.tudelft.nl> writes:

> On Saturday 17 January 2004 14:37, Richard Kenner wrote:
>>     If we want to develop a GCC 3.5 release without Tree-SSA, then we
>>     should have specific, non-SSA feature goals that we want to
>>     accomplish.  Otherwise, what is the benefit of GCC 3.5 over additional
>>     point releases of GCC 3.4 stable branch?
>>
>> I don't understand your point.  Since GCC is a volunteer project, there is
>> no practical way of forming such "goals" or schedules.  We presume, unless
>> there's evidence to the contrary that people are going to be working on
>> improvements to GCC into the future.
>
> That is what everyone is saying every time somebody suggests we should
> have goals for the next release.
>
> Result: everyone just starts hacking without any form of plan, and we
> end up with lots of half-finished efforts.
>
> It is OK to say: "For this release our goals are...".  Get a good number
> of people (volunteers) to agree on that, and you can make those goals.
> Do nothing, and nothing happens.

I agree.  Let's write down which goals we want to have - and strive to
get them done.  If we figure out after some time that some goals are
not realistic in our timeframe, then move them to the next release
(so, we always have two lists: one for current release and one for the
release afterwards).  But having some goals that are understood, helps
to concentrate effort and gives developers some ideas what they should
do.

For example some goals might be:

For 3.5:
- variable tracking
- Tree-SSA with:
  * at least same performance as 3.4
  * published interfaces between frontends and middle-end
- Fortran95 front-end
- ...

After 3.6:
- vectorization
- ...

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: [RFC] Contributing tree-ssa to mainline

[Daniel Berlin]

On Jan 17, 2004, at 9:53 AM, Florian Weimer wrote:

> Daniel Berlin wrote:
>
>> As Diego stated when SRA was committed, the following limitation 
>> exists:
>> /* Maximum number of fields that a structure should have to be
>> scalarized.
>>    FIXME  This limit has been arbitrarily set to 5.  Experiment to 
>> find
>> a
>>     sensible setting.  */
>> #define MAX_NFIELDS_FOR_SRA 5\x03
>>
>> This was done, IIRC, to avoid severely increased register pressure.
>>
>> If you want SRA to do something on your structure, you'll need to
>> increase that limit
>
> If I go down to two fields/tuples of length two, the optimization
> doesn't kick in, either.  8-(
Hmmm. Interesting.
Can you file a bug report with this testcase (the length 2, which 
*should* be taken care of already), so it can be tracked?

--Dan

Re: [RFC] Contributing tree-ssa to mainline

[Jan Hubicka]

> > 
> > Hi Jan,
> > > Perhaps you could provide details of where you 2 or 3% comes from?
> > 
> > My apologies.  The two URLs given in your posting do indeed show
> > GCC 3.3 only about 6% behind Intel 7.0, with aggressive optimizations.
> > Indeed, this is a much fairer comparison than the "apples-and-oranges"
> > results linked from Andreas' site.
> 
> This compare to hammer branch GCC 3.3 and 64bit to 32bit mode, so it is
> not also really fine comparsion.  (attached)
> I will have 32bit results on the same hardware bu tomorrow.  I already
> checked that mainline outperforms hammer branch at -O2, at aggressive
> settings we have more issues, but I am just analyzing them and at least
> eon I analyzed yesterday was simple defect in profiling and
> -fwritable-strings.
> 
> In fact we misscompile following constructor:
> 
> struct a{
> 	int a; char *b;
> } a={1,"ahoj"};
> 
> if there are no plans to fix this deprecated feature, I would preffer to
> just kill it as this is important defect and it took me about 2 hours
> yesterday to work out why profiling is broken.
> 
> Also the peak runs suffer from too large inlining limit I already fixed.
> another problem is too large unrolling limit I will try to trottle and
> produce patch too.
> 
> I will post more complette results once I am done.
> 
> Honza
> 
> Hi,
> Here's the requested output from gcc-benchmark.
> Base Compiler: hamer branch
> Peak Compiler: mainline
> cflags base: -O2
> cflags peak: -O2
> Iterations: 1
> Running on: vivaldi
> Hardware: x86_64/AMD Opteron(tm) Processor 242 at 1593.799
> PDO for base and peak: No
> PDO for peak only: No
> Using gfortran instead of F77: No
> This run is: SPECint

I forgot to note.  These runs were done with oprofile running so they
are not comparable to any other published results.

Honza

Re: [RFC] Contributing tree-ssa to mainline

[Diego Novillo]

On Sat, 2004-01-17 at 08:47, Florian Weimer wrote:

> (Probably this is a different issue, but I had hoped that the tree-ssa
> branch would somehow improve things in this area.)
> 
Could you open a PR for this test case and assign it to me?


Thanks.  Diego.

Re: [RFC] Contributing tree-ssa to mainline

[Scott Robert Ladd]

Diego Novillo wrote:
> By its very nature, mainline attracts quite a bit more development than
> an obscure branch.

Actually, they attract *different kinds* of development. SSA attarcts 
people, such as myself, who want certain new features; mailine gets the 
majority of the day-to-day effort.

It would be best if the twain met sooner than later.

-- 
Scott Robert Ladd
Coyote Gulch Productions (http://www.coyotegulch.com)
Software Invention for High-Performance Computing

Re: [RFC] Contributing tree-ssa to mainline

[Florian Weimer]

Daniel Berlin wrote:

> As Diego stated when SRA was committed, the following limitation exists:
> /* Maximum number of fields that a structure should have to be 
> scalarized.
>    FIXME  This limit has been arbitrarily set to 5.  Experiment to find 
> a
>     sensible setting.  */
> #define MAX_NFIELDS_FOR_SRA 5\x03
> 
> This was done, IIRC, to avoid severely increased register pressure.
> 
> If you want SRA to do something on your structure, you'll need to 
> increase that limit

If I go down to two fields/tuples of length two, the optimization
doesn't kick in, either.  8-(

Re: [RFC] Contributing tree-ssa to mainline

[Scott Robert Ladd]

Richard Kenner wrote:
> Sure, but in that situation I feel it should stay in a branch until those
> "possibilities" have indeed been "opened up".  Otherwise, it's a lot of
> extra code to maintain and overhead to pay for in compilation without any
> known benefit.  Newer is not always better.  Indeed I find that for most
> of the products I buy, the quality is often *far* worse than that of the
> same product purchased decades ago.

You are correct.

I wish I were more conversant in the internal mechanations of compilers; 
at the moment, I base my opinion on what I'm told by people who appear 
to "know their stuff."

I have two major interests in the future of GCC: OpenMP and Fortran.

When we first created the OpenMP project last year, I was informed that 
the existing GCC architecture was ill-suited to the task. Therefore, 
gomp (the GNU OpenMP project) was explicitly founded on tree-ssa. 
Perhaps someone else (Steven?) can fill in the reasons for this choice.

We've already had a debate about back-porting gfortran to the 3.4 
architecture; again, others are more qualified to define the technical 
challenges. What I do know is that the gfortran developers seem very 
focused on tree-ssa.

If we do *not* move SSA into mainline, then we need to discuss how (and 
if) these important features (Fortran 95 and OpenMP) can be implemented 
in a timely fashion under the existing architecture.

OpenMP will become a major issue within 18 months; regardless of what 
happens to Fortran, the increasing parallelism in hardware, Intel's 
strong support of OpenMP, and existing practice in high-performance 
computing all suggest that this issue is important to GCC.

> Whether or not (and to what extent) the tree-ssa infrastructure is
> "significant" can't be made by arguments over possibilities it might open
> up, but by demonstrating those possibilities.

Someone needs to step up and explain why certain new features are only 
being developed under tree-ssa. Is it due to technical concerns (as I 
understand it), or not?

-- 
Scott Robert Ladd
Coyote Gulch Productions (http://www.coyotegulch.com)
Software Invention for High-Performance Computing

Re: [RFC] Contributing tree-ssa to mainline

[Daniel Berlin]

On Jan 17, 2004, at 8:47 AM, Florian Weimer wrote:

> Diego Novillo wrote:
>
>> On Fri, 2004-01-16 at 22:24, Richard Kenner wrote:
>>
>>> Remember that the last time we had the discussion of the timing of 
>>> tree-ssa,
>>> people claimed it was "essential" for 3.5 since there was a 
>>> tremendous
>>> improvement on some C++ cases.  So let's see those cases.
>>>
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12747
>
> I've been toying with boost::tie() lately, and the temporary tuple is
> still *not* eleminated in the interesting cases, unfortunately.
>
> For an example, look at the code generated for bar(foo&) and baz(foo&)
> below, which should be quite similar once the template metaprogram has
> been expanded.  However, in the template case, indirection through
> references still clutters the generated machine code.
>
> We can do better; bar_neg(foo&) and baz_neg(foo&) show this.  The
> template version results in identical code in this case, except that
> unnecessary space is allocated on the stack.  (However, this
> optimization happens on mainline, too, not just on the branch.)

> (Probably this is a different issue, but I had hoped that the tree-ssa
> branch would somehow improve things in this area.)
>
As Diego stated when SRA was committed, the following limitation exists:
/* Maximum number of fields that a structure should have to be 
scalarized.
    FIXME  This limit has been arbitrarily set to 5.  Experiment to find 
a
     sensible setting.  */
#define MAX_NFIELDS_FOR_SRA 5\x03

This was done, IIRC, to avoid severely increased register pressure.

If you want SRA to do something on your structure, you'll need to 
increase that limit

Re: [RFC] Contributing tree-ssa to mainline

[Jan Hubicka]

> 
> Hi Jan,
> > Perhaps you could provide details of where you 2 or 3% comes from?
> 
> My apologies.  The two URLs given in your posting do indeed show
> GCC 3.3 only about 6% behind Intel 7.0, with aggressive optimizations.
> Indeed, this is a much fairer comparison than the "apples-and-oranges"
> results linked from Andreas' site.

This compare to hammer branch GCC 3.3 and 64bit to 32bit mode, so it is
not also really fine comparsion.  (attached)
I will have 32bit results on the same hardware bu tomorrow.  I already
checked that mainline outperforms hammer branch at -O2, at aggressive
settings we have more issues, but I am just analyzing them and at least
eon I analyzed yesterday was simple defect in profiling and
-fwritable-strings.

In fact we misscompile following constructor:

struct a{
	int a; char *b;
} a={1,"ahoj"};

if there are no plans to fix this deprecated feature, I would preffer to
just kill it as this is important defect and it took me about 2 hours
yesterday to work out why profiling is broken.

Also the peak runs suffer from too large inlining limit I already fixed.
another problem is too large unrolling limit I will try to trottle and
produce patch too.

I will post more complette results once I am done.

Honza

Hi,
Here's the requested output from gcc-benchmark.
Base Compiler: hamer branch
Peak Compiler: mainline
cflags base: -O2
cflags peak: -O2
Iterations: 1
Running on: vivaldi
Hardware: x86_64/AMD Opteron(tm) Processor 242 at 1593.799
PDO for base and peak: No
PDO for peak only: No
Using gfortran instead of F77: No
This run is: SPECint

Please direct questions about this to aj@suse.de

Size of binaries:
 164.gzip: Base: 62716 bytes
 164.gzip: Peak: 62604 bytes
 175.vpr: Base: 167701 bytes
 175.vpr: Peak: 167354 bytes
 176.gcc: Base: 1612426 bytes
 176.gcc: Peak: 1605449 bytes
 181.mcf: Base: 25589 bytes
 181.mcf: Peak: 25525 bytes
 186.crafty: Base: 224570 bytes
 186.crafty: Peak: 224346 bytes
 197.parser: Base: 143696 bytes
 197.parser: Peak: 143568 bytes
 252.eon: Base: 604611 bytes
 252.eon: Peak: 635561 bytes
 253.perlbmk: Base: 667061 bytes
 253.perlbmk: Peak: 666917 bytes
 254.gap: Base: 542438 bytes
 254.gap: Peak: 542358 bytes
 255.vortex: Base: 678497 bytes
 255.vortex: Peak: 686898 bytes
 256.bzip2: Base: 53904 bytes
 256.bzip2: Peak: 53888 bytes
 300.twolf: Base: 225871 bytes
 300.twolf: Peak: 221423 bytes
 =============================
 Total: Base: 5009080 bytes
 Total: Peak: 5035891 bytes

Compile times for benchmarks:
164.gzip base: 2 s
175.vpr base: 5 s
176.gcc base: 55 s
181.mcf base: 1 s
186.crafty base: 10 s
197.parser base: 5 s
252.eon base: 100 s
253.perlbmk base: 27 s
254.gap base: 20 s
255.vortex base: 19 s
256.bzip2 base: 1 s
300.twolf base: 12 s
164.gzip peak: 2 s
175.vpr peak: 6 s
176.gcc peak: 57 s
181.mcf peak: 1 s
186.crafty peak: 10 s
197.parser peak: 5 s
252.eon peak: 105 s
253.perlbmk peak: 27 s
254.gap peak: 20 s
255.vortex peak: 20 s
256.bzip2 peak: 1 s
300.twolf peak: 13 s
======================================
Total time for base compilation: 257 s
Total time for peak compilation: 267 s

GCC was configured as: configure --enable-threads=posix --enable-languages="c,c++" --disable-multilib
GCC bootstrap times for 'make -j2 bootstrap && make install':
Base compiler: 691 s
Peak compiler: 662 s


--_----------=_1074261898165450
Content-Disposition: inline; filename="CINT2000.052.asc"
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; name="CINT2000.052.asc"

##############################################################################
#   INVALID RUN INVALID RUN INVALID RUN INVALID RUN INVALID RUN INVALID RUN  #
#                                                                            #
# 'reportable' flag not set during run                                       #
# 254.gap base did not have enough runs!                                     #
# 256.bzip2 base did not have enough runs!                                   #
# 255.vortex base did not have enough runs!                                  #
# 175.vpr base did not have enough runs!                                     #
# 164.gzip base did not have enough runs!                                    #
# 253.perlbmk base did not have enough runs!                                 #
# 186.crafty base did not have enough runs!                                  #
# 176.gcc base did not have enough runs!                                     #
# 252.eon base did not have enough runs!                                     #
# 197.parser base did not have enough runs!                                  #
# 300.twolf base did not have enough runs!                                   #
# 181.mcf base did not have enough runs!                                     #
# 254.gap peak did not have enough runs!                                     #
# 256.bzip2 peak did not have enough runs!                                   #
# 255.vortex peak did not have enough runs!                                  #
# 175.vpr peak did not have enough runs!                                     #
# 164.gzip peak did not have enough runs!                                    #
# 253.perlbmk peak did not have enough runs!                                 #
# 186.crafty peak did not have enough runs!                                  #
# 176.gcc peak did not have enough runs!                                     #
# 252.eon peak did not have enough runs!                                     #
# 197.parser peak did not have enough runs!                                  #
# 300.twolf peak did not have enough runs!                                   #
# 181.mcf peak did not have enough runs!                                     #
# Error 252.eon: Child returned with invalid return code                     #
# Error 252.eon: Output miscompare                                           #
#                                                                            #
#   INVALID RUN INVALID RUN INVALID RUN INVALID RUN INVALID RUN INVALID RUN  #
##############################################################################
                            SPEC CINT2000 Summary
                               Unknown Unknown
                           Tested by SuSE Linux AG
                           Fri Jan 16 13:30:03 2004

SPEC License #1922  Test date: 2004-01-16   Hardware availability: today
Tester: Andreas Jaeger, SuSE Linux AG       Software availability: Now

                                     Estimated                     Estimated
                   Base      Base      Base      Peak      Peak      Peak
   Benchmarks    Ref Time  Run Time   Ratio    Ref Time  Run Time   Ratio
   ------------  --------  --------  --------  --------  --------  --------
   164.gzip          1400     180         780*     1400  179            783*
   175.vpr           1400     201         698*     1400  203            689*
   176.gcc           1100     129         853*     1100  128            857*
   181.mcf           1800     520         346*     1800  518            347*
   186.crafty        1000      70.4      1421*     1000   72.4         1381*
   197.parser        1800     335         537*     1800  333            541*
   252.eon           1300     110        1187*     1300    0.0285          X
   253.perlbmk       1800     192         937*     1800  185            972*
   254.gap           1100     151         730*     1100  147            747*
   255.vortex        1900     172        1103*     1900  162           1170*
   256.bzip2         1500     198         757*     1500  200            751*
   300.twolf         3000     381         788*     3000  376            797*
   ========================================================================
   164.gzip          1400     180         780*     1400  179            783*
   175.vpr           1400     201         698*     1400  203            689*
   176.gcc           1100     129         853*     1100  128            857*
   181.mcf           1800     520         346*     1800  518            347*
   186.crafty        1000      70.4      1421*     1000   72.4         1381*
   197.parser        1800     335         537*     1800  333            541*
   252.eon           1300     110        1187*                             
   253.perlbmk       1800     192         937*     1800  185            972*
   254.gap           1100     151         730*     1100  147            747*
   255.vortex        1900     172        1103*     1900  162           1170*
   256.bzip2         1500     198         757*     1500  200            751*
   300.twolf         3000     381         788*     3000  376            797*
   Est. SPECint_base2000                  797
   Est. SPECint2000                                                     775


                                   HARDWARE
                                   --------
     Hardware Vendor: Unknown
          Model Name: Unknown
                 CPU: AMD Opteron(tm) Processor 242
             CPU MHz: 1593.799
                 FPU: Integrated
      CPU(s) enabled: 2
    CPU(s) orderable: 1,2
            Parallel: No
       Primary Cache:  
     Secondary Cache: 1024 KB
            L3 Cache: N/A
         Other Cache: N/A
              Memory: 992 MB
      Disk Subsystem: Unknown
      Other Hardware: Ethernet


                                   SOFTWARE
                                   --------
    Operating System: SuSE Linux 9.0 (x86-64)
            Compiler: GCC CVS
         File System: Linux/reiserfs
        System State: Multi-User


                                    NOTES
                                    -----
     
     Base flags: -O2
     Compiler: Unspecified
     Peak flags: -O2
     Compiler: Unspecified
     To compile and execute eon correctly the following extra flags
     are used for compilation: -ffast-math -fwritable-strings.
##############################################################################
#   INVALID RUN INVALID RUN INVALID RUN INVALID RUN INVALID RUN INVALID RUN  #
#                                                                            #
# 'reportable' flag not set during run                                       #
# 254.gap base did not have enough runs!                                     #
# 256.bzip2 base did not have enough runs!                                   #
# 255.vortex base did not have enough runs!                                  #
# 175.vpr base did not have enough runs!                                     #
# 164.gzip base did not have enough runs!                                    #
# 253.perlbmk base did not have enough runs!                                 #
# 186.crafty base did not have enough runs!                                  #
# 176.gcc base did not have enough runs!                                     #
# 252.eon base did not have enough runs!                                     #
# 197.parser base did not have enough runs!                                  #
# 300.twolf base did not have enough runs!                                   #
# 181.mcf base did not have enough runs!                                     #
# 254.gap peak did not have enough runs!                                     #
# 256.bzip2 peak did not have enough runs!                                   #
# 255.vortex peak did not have enough runs!                                  #
# 175.vpr peak did not have enough runs!                                     #
# 164.gzip peak did not have enough runs!                                    #
# 253.perlbmk peak did not have enough runs!                                 #
# 186.crafty peak did not have enough runs!                                  #
# 176.gcc peak did not have enough runs!                                     #
# 252.eon peak did not have enough runs!                                     #
# 197.parser peak did not have enough runs!                                  #
# 300.twolf peak did not have enough runs!                                   #
# 181.mcf peak did not have enough runs!                                     #
# Error 252.eon: Child returned with invalid return code                     #
# Error 252.eon: Output miscompare                                           #
#                                                                            #
#   INVALID RUN INVALID RUN INVALID RUN INVALID RUN INVALID RUN INVALID RUN  #
##############################################################################
-----------------------------------------------------------------------------
For questions about this result, please contact the tester.
For other inquiries, please contact webmaster@spec.org.
Copyright 1999-2001 Standard Performance Evaluation Corporation
Generated on Fri Jan 16 15:04:57 2004 by SPEC CPU2000 ASCII formatter v2.1

--_----------=_1074261898165450--

Hi,
Here's the requested output from gcc-benchmark.
Base Compiler: hammer branch
Peak Compiler: mainline
cflags base: -O3 -ftracer -funroll-loops -ffast-math -fpeel-loops
cflags peak: -O3 -ftracer -funroll-loops -ffast-math -fpeel-loops -fprofile-values -fvpt
Iterations: 1
Running on: vivaldi
Hardware: x86_64/AMD Opteron(tm) Processor 242 at 1593.799
PDO for base and peak: Yes
PDO for peak only: No
Using gfortran instead of F77: No
This run is: SPECint

Please direct questions about this to aj@suse.de

Size of binaries:
 164.gzip: Base: 74699 bytes
 164.gzip: Peak: 76185 bytes
 175.vpr: Base: 189819 bytes
 175.vpr: Peak: 198472 bytes
 176.gcc: Base: 2007407 bytes
 176.gcc: Peak: 2080007 bytes
 181.mcf: Base: 29853 bytes
 181.mcf: Peak: 29821 bytes
 186.crafty: Base: 247042 bytes
 186.crafty: Peak: 241570 bytes
 197.parser: Base: 214742 bytes
 197.parser: Peak: 215766 bytes
 252.eon: Base: 625272 bytes
 252.eon: Peak: 655316 bytes
 253.perlbmk: Base: 768347 bytes
 253.perlbmk: Peak: 775934 bytes
 254.gap: Base: 625415 bytes
 254.gap: Peak: 616535 bytes
 255.vortex: Base: 694349 bytes
 255.vortex: Peak: 694612 bytes
 256.bzip2: Base: 78776 bytes
 256.bzip2: Peak: 66472 bytes
 300.twolf: Base: 246508 bytes
 300.twolf: Peak: 250179 bytes
 =============================
 Total: Base: 5802229 bytes
 Total: Peak: 5900869 bytes

Compile times for benchmarks:
164.gzip base: 7 s
175.vpr base: 19 s
176.gcc base: 228 s
181.mcf base: 4 s
186.crafty base: 26 s
197.parser base: 19 s
252.eon base: 221 s
253.perlbmk base: 96 s
254.gap base: 70 s
255.vortex base: 53 s
256.bzip2 base: 6 s
300.twolf base: 33 s
164.gzip peak: 7 s
175.vpr peak: 22 s
176.gcc peak: 250 s
181.mcf peak: 3 s
186.crafty peak: 26 s
197.parser peak: 21 s
252.eon peak: 242 s
253.perlbmk peak: 96 s
254.gap peak: 74 s
255.vortex peak: 52 s
256.bzip2 peak: 5 s
300.twolf peak: 38 s
======================================
Total time for base compilation: 782 s
Total time for peak compilation: 836 s

GCC was configured as: configure --enable-threads=posix --enable-languages="c,c++" --disable-multilib
GCC bootstrap times for 'make -j2 bootstrap && make install':
Base compiler: 695 s
Peak compiler: 667 s


--_----------=_107429000198830
Content-Disposition: inline; filename="CINT2000.058.asc"
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; name="CINT2000.058.asc"

##############################################################################
#   INVALID RUN INVALID RUN INVALID RUN INVALID RUN INVALID RUN INVALID RUN  #
#                                                                            #
# 'reportable' flag not set during run                                       #
# 254.gap base did not have enough runs!                                     #
# 256.bzip2 base did not have enough runs!                                   #
# 255.vortex base did not have enough runs!                                  #
# 175.vpr base did not have enough runs!                                     #
# 164.gzip base did not have enough runs!                                    #
# 253.perlbmk base did not have enough runs!                                 #
# 186.crafty base did not have enough runs!                                  #
# 176.gcc base did not have enough runs!                                     #
# 252.eon base did not have enough runs!                                     #
# 197.parser base did not have enough runs!                                  #
# 300.twolf base did not have enough runs!                                   #
# 181.mcf base did not have enough runs!                                     #
# 254.gap peak did not have enough runs!                                     #
# 256.bzip2 peak did not have enough runs!                                   #
# 255.vortex peak did not have enough runs!                                  #
# 175.vpr peak did not have enough runs!                                     #
# 164.gzip peak did not have enough runs!                                    #
# 253.perlbmk peak did not have enough runs!                                 #
# 186.crafty peak did not have enough runs!                                  #
# 176.gcc peak did not have enough runs!                                     #
# 252.eon peak did not have enough runs!                                     #
# 197.parser peak did not have enough runs!                                  #
# 300.twolf peak did not have enough runs!                                   #
# 181.mcf peak did not have enough runs!                                     #
#                                                                            #
#   INVALID RUN INVALID RUN INVALID RUN INVALID RUN INVALID RUN INVALID RUN  #
##############################################################################
                            SPEC CINT2000 Summary
                               Unknown Unknown
                           Tested by SuSE Linux AG
                           Fri Jan 16 20:57:07 2004

SPEC License #1922  Test date: 2004-01-16   Hardware availability: today
Tester: Andreas Jaeger, SuSE Linux AG       Software availability: Now

                                     Estimated                     Estimated
                   Base      Base      Base      Peak      Peak      Peak
   Benchmarks    Ref Time  Run Time   Ratio    Ref Time  Run Time   Ratio
   ------------  --------  --------  --------  --------  --------  --------
   164.gzip          1400     167         839*     1400     164         853*
   175.vpr           1400     191         735*     1400     193         726*
   176.gcc           1100     122         898*     1100     123         893*
   181.mcf           1800     514         350*     1800     512         352*
   186.crafty        1000      72.1      1388*     1000      71.0      1409*
   197.parser        1800     273         660*     1800     275         653*
   252.eon           1300      90.4      1438*     1300     114        1141*
   253.perlbmk       1800     174        1037*     1800     163        1101*
   254.gap           1100     141         779*     1100     141         783*
   255.vortex        1900     157        1209*     1900     154        1231*
   256.bzip2         1500     186         805*     1500     191         787*
   300.twolf         3000     366         819*     3000     374         802*
   ========================================================================
   164.gzip          1400     167         839*     1400     164         853*
   175.vpr           1400     191         735*     1400     193         726*
   176.gcc           1100     122         898*     1100     123         893*
   181.mcf           1800     514         350*     1800     512         352*
   186.crafty        1000      72.1      1388*     1000      71.0      1409*
   197.parser        1800     273         660*     1800     275         653*
   252.eon           1300      90.4      1438*     1300     114        1141*
   253.perlbmk       1800     174        1037*     1800     163        1101*
   254.gap           1100     141         779*     1100     141         783*
   255.vortex        1900     157        1209*     1900     154        1231*
   256.bzip2         1500     186         805*     1500     191         787*
   300.twolf         3000     366         819*     3000     374         802*
   Est. SPECint_base2000                  860
   Est. SPECint2000                                                     847


                                   HARDWARE
                                   --------
     Hardware Vendor: Unknown
          Model Name: Unknown
                 CPU: AMD Opteron(tm) Processor 242
             CPU MHz: 1593.799
                 FPU: Integrated
      CPU(s) enabled: 2
    CPU(s) orderable: 1,2
            Parallel: No
       Primary Cache:  
     Secondary Cache: 1024 KB
            L3 Cache: N/A
         Other Cache: N/A
              Memory: 992 MB
      Disk Subsystem: Unknown
      Other Hardware: Ethernet


                                   SOFTWARE
                                   --------
    Operating System: Linux 2.6.0-3-smp
            Compiler: GCC CVS
         File System: Linux/reiserfs
        System State: Multi-User


                                    NOTES
                                    -----
     
     Base flags: -O3 -ftracer -funroll-loops -ffast-math -fpeel-loops
     Compiler: Unspecified
     Peak flags: -O3 -ftracer -funroll-loops -ffast-math -fpeel-loops -fprofile-values -fvpt
     Compiler: Unspecified
     Run with profile directed optimizations for both base and peak
     (first pass has -fprofile-arcs, second has -fbranch-probabilities)
     To compile and execute eon correctly the following extra flags
     are used for compilation: -ffast-math -fwritable-strings.
##############################################################################
#   INVALID RUN INVALID RUN INVALID RUN INVALID RUN INVALID RUN INVALID RUN  #
#                                                                            #
# 'reportable' flag not set during run                                       #
# 254.gap base did not have enough runs!                                     #
# 256.bzip2 base did not have enough runs!                                   #
# 255.vortex base did not have enough runs!                                  #
# 175.vpr base did not have enough runs!                                     #
# 164.gzip base did not have enough runs!                                    #
# 253.perlbmk base did not have enough runs!                                 #
# 186.crafty base did not have enough runs!                                  #
# 176.gcc base did not have enough runs!                                     #
# 252.eon base did not have enough runs!                                     #
# 197.parser base did not have enough runs!                                  #
# 300.twolf base did not have enough runs!                                   #
# 181.mcf base did not have enough runs!                                     #
# 254.gap peak did not have enough runs!                                     #
# 256.bzip2 peak did not have enough runs!                                   #
# 255.vortex peak did not have enough runs!                                  #
# 175.vpr peak did not have enough runs!                                     #
# 164.gzip peak did not have enough runs!                                    #
# 253.perlbmk peak did not have enough runs!                                 #
# 186.crafty peak did not have enough runs!                                  #
# 176.gcc peak did not have enough runs!                                     #
# 252.eon peak did not have enough runs!                                     #
# 197.parser peak did not have enough runs!                                  #
# 300.twolf peak did not have enough runs!                                   #
# 181.mcf peak did not have enough runs!                                     #
#                                                                            #
#   INVALID RUN INVALID RUN INVALID RUN INVALID RUN INVALID RUN INVALID RUN  #
##############################################################################
-----------------------------------------------------------------------------
For questions about this result, please contact the tester.
For other inquiries, please contact webmaster@spec.org.
Copyright 1999-2001 Standard Performance Evaluation Corporation
Generated on Fri Jan 16 22:53:20 2004 by SPEC CPU2000 ASCII formatter v2.1

--_----------=_107429000198830--

Re: [RFC] Contributing tree-ssa to mainline

[Jan Hubicka]

> 
> On Sat, 17 Jan 2004, Jan Hubicka wrote:
> > > My greatest disappointment working on GCC's optimizations, is that
> > > try as I might I've only ever been able to push Andreas' SPECcpu2000
> > > benchmarks perhaps a percentage point or two higher.  This on a platform
> > > where Microsoft's compilers score about 20% higher.  Intel similarly
> > > claims about 20% better performance than GCC on average.
> >
> > How did you got to this number?
> > This is definitly not the case of SPECint scpres I saw.  My experience
> > is that we are about 2-3% behind AMD published results in 32bit mode.
> 
> The published figures are on Andreas' site for the world to see.
> http://www.suse.de/~aj/SPEC/
> 
> If you click on "SPECint2000 results (permanent runs, non-reportable)"
> you get mainline's current performance, which from the graph at the
> bottom is just about 400 as of January 17th 2004.
> 
> If you then go to the section entitled "Comparisons with Other Compilers"
> and click on the "SPECint200 in 1.2GHZ AMD Athlon", which is described
> as "these results should give an indication of how good/bad GCC is",
> you'll see a SPEC report with SPECint2000 of 496.  And that was with
> the Intel 5.0 compiler!
> 
> The difference between 400 and 500 is about 20%.

You missed the fact that published results are on 1.2Ghz athlon with
more modern core, compared to our testers running 1.33.
There are unforutnately no published results for 1.33 Athlons
Additionally the settings are more comparable with our peak results as
ICC does profile feedback, unrolling, inlining, frame pointer omitting
and other stuff in the baseline results.

Finally there is noticeable difference caused by runtime library that
contains optimized malloc and few other tricks.
> 
> 
> Perhaps you could provide details of where you 2 or 3% comes from?

I did ICC runs with same config options myself on same hardware as
periodic testers use.  I am not sure I still have the numbers, but I
will try to dig out.

You can look at http://www.suse.de/~aj/SPEC/amd64 that contains bars for
ICC and 32bit compilers.
If I compute geometric average myself, i get 878 ICC score.  Compare it
to 820 produced by GCC peak in 32bit compilation and you get 7%
difference and take into account that profile feedback.
Then look at my GCC summit paper.  It contains tests with similar set of
opotimizations and it claims that 7.87% can be gained if Andreas used
PDO.

I need to produce true runs instead of such a hints, but it is clear
that we are not 20% behind at all.

Honza
> 
> Roger
> --

Re: [RFC] Contributing tree-ssa to mainline

[Roger Sayle]

Hi Jan,
> Perhaps you could provide details of where you 2 or 3% comes from?

My apologies.  The two URLs given in your posting do indeed show
GCC 3.3 only about 6% behind Intel 7.0, with aggressive optimizations.
Indeed, this is a much fairer comparison than the "apples-and-oranges"
results linked from Andreas' site.

Clearly the situation is not as grim as I'd believed.

Roger
--

Re: [RFC] Contributing tree-ssa to mainline

[Roger Sayle]

On Sat, 17 Jan 2004, Jan Hubicka wrote:
> > My greatest disappointment working on GCC's optimizations, is that
> > try as I might I've only ever been able to push Andreas' SPECcpu2000
> > benchmarks perhaps a percentage point or two higher.  This on a platform
> > where Microsoft's compilers score about 20% higher.  Intel similarly
> > claims about 20% better performance than GCC on average.
>
> How did you got to this number?
> This is definitly not the case of SPECint scpres I saw.  My experience
> is that we are about 2-3% behind AMD published results in 32bit mode.

The published figures are on Andreas' site for the world to see.
http://www.suse.de/~aj/SPEC/

If you click on "SPECint2000 results (permanent runs, non-reportable)"
you get mainline's current performance, which from the graph at the
bottom is just about 400 as of January 17th 2004.

If you then go to the section entitled "Comparisons with Other Compilers"
and click on the "SPECint200 in 1.2GHZ AMD Athlon", which is described
as "these results should give an indication of how good/bad GCC is",
you'll see a SPEC report with SPECint2000 of 496.  And that was with
the Intel 5.0 compiler!

The difference between 400 and 500 is about 20%.


Perhaps you could provide details of where you 2 or 3% comes from?

Roger
--

Re: [RFC] Contributing tree-ssa to mainline

[Steven Bosscher]

On Saturday 17 January 2004 14:37, Richard Kenner wrote:
>     If we want to develop a GCC 3.5 release without Tree-SSA, then we
>     should have specific, non-SSA feature goals that we want to
>     accomplish.  Otherwise, what is the benefit of GCC 3.5 over additional
>     point releases of GCC 3.4 stable branch?
>
> I don't understand your point.  Since GCC is a volunteer project, there is
> no practical way of forming such "goals" or schedules.  We presume, unless
> there's evidence to the contrary that people are going to be working on
> improvements to GCC into the future.

That is what everyone is saying every time somebody suggests we should
have goals for the next release.

Result: everyone just starts hacking without any form of plan, and we
end up with lots of half-finished efforts.

It is OK to say: "For this release our goals are...".  Get a good number
of people (volunteers) to agree on that, and you can make those goals.
Do nothing, and nothing happens.

Gr.
Steven

Re: [RFC] Contributing tree-ssa to mainline

[Jan Hubicka]

> 
> On Sat, 17 Jan 2004, Steven Bosscher wrote:
> > On Saturday 17 January 2004 03:30, Richard Kenner wrote:
> > > My feeling is that "success" would be in showing at least one class of code
> > > where we see very significantly better code (at least a factor of two) and
> > > we see significant (around 10-20%) performance improvement in a larger
> > > class of test cases.
> >
> > You must be joking.  I've added this beautiful quip to bugzilla:
> >
> > Moore's Law: "Advances in hardware double computing power every 18 months".
> > Proebsting's law: "Advances in compiler optimizations double computing
> > power every 18 years".
> >
> > Expecting tree-ssa to produce code better by a factor of two is simply
> > unreasonable.
> 
> 
> Whilst I agree that expecting a factor of two is asking for miracles,
> there are clearly significant gains to be made without pushing the
> envelope of current compiler theory.
> 
> My greatest disappointment working on GCC's optimizations, is that
> try as I might I've only ever been able to push Andreas' SPECcpu2000
> benchmarks perhaps a percentage point or two higher.  This on a platform
> where Microsoft's compilers score about 20% higher.  Intel similarly
> claims about 20% better performance than GCC on average.

How did you got to this number?
This is definitly not the case of SPECint scpres I saw.  My experience
is that we are about 2-3% behind AMD published results in 32bit mode.
On K8 in 64bit mode we get very comparable in between 64bit and 32bit on
slower CPUs.  The difference grow as the CPUs get faster because of
higher memory overhead of many benchmarks.  The published results are 7%
worse:
http://www.spec.org/cpu2000/results/res2003q4/cpu2000-20030922-02516.asc
http://www.spec.org/cpu2000/results/res2003q4/cpu2000-20030922-02519.asc
but this really suffers from apples to oranges comparsion.

This explains why pushing the scores up is very dificult.

Honza

Re: [RFC] Contributing tree-ssa to mainline

[Florian Weimer]

Diego Novillo wrote:

> On Fri, 2004-01-16 at 22:24, Richard Kenner wrote:
> 
> > Remember that the last time we had the discussion of the timing of tree-ssa,
> > people claimed it was "essential" for 3.5 since there was a tremendous
> > improvement on some C++ cases.  So let's see those cases.
> >
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12747

I've been toying with boost::tie() lately, and the temporary tuple is
still *not* eleminated in the interesting cases, unfortunately.

For an example, look at the code generated for bar(foo&) and baz(foo&)
below, which should be quite similar once the template metaprogram has
been expanded.  However, in the template case, indirection through
references still clutters the generated machine code.

We can do better; bar_neg(foo&) and baz_neg(foo&) show this.  The
template version results in identical code in this case, except that
unnecessary space is allocated on the stack.  (However, this
optimization happens on mainline, too, not just on the branch.)

(Probably this is a different issue, but I had hoped that the tree-ssa
branch would somehow improve things in this area.)

#include <boost/tuple/tuple.hpp>

struct foo {
  int a, b, c, d, e, f, g, h, i, j;
};

template <typename T>
struct make_abs_t
{
  static void doit(const T& t)
  {
    if (t.head < 0) {
      t.head = -t.head;
    }
    make_abs_t<typename T::tail_type>::doit(t.tail);
  }
};

template <typename Car>
struct make_abs_t<boost::tuples::cons<Car, boost::tuples::null_type> >
{
  static void doit(const boost::tuples::cons<Car, boost::tuples::null_type>& t)
  {
    if (t.head < 0) {
      t.head = -t.head;
    }
  }
};

template <typename T>
inline void make_abs(const T& t)
{
  make_abs_t<T>::doit(t);
}

void bar(foo& x)
{
  make_abs(boost::tie(x.a, x.b, x.c, x.d, x.e, x.f, x.g, x.h, x.i, x.j));
}

void baz(foo& x)
{
  if (x.a < 0) x.a = -x.a;
  if (x.b < 0) x.b = -x.b;
  if (x.c < 0) x.c = -x.c;
  if (x.d < 0) x.d = -x.d;
  if (x.e < 0) x.e = -x.e;
  if (x.f < 0) x.f = -x.f;
  if (x.g < 0) x.g = -x.g;
  if (x.h < 0) x.h = -x.h;
  if (x.i < 0) x.i = -x.i;
  if (x.j < 0) x.j = -x.j;
}

template <typename T>
struct make_neg_t
{
  static void doit(const T& t)
  {
    t.head = -t.head;
    make_neg_t<typename T::tail_type>::doit(t.tail);
  }
};

template <typename Car>
struct make_neg_t<boost::tuples::cons<Car, boost::tuples::null_type> >
{
  static void doit(const boost::tuples::cons<Car, boost::tuples::null_type>& t)
  {
    t.head = -t.head;
  }
};

template <typename T>
inline void make_neg(const T& t)
{
  make_neg_t<T>::doit(t);
}

void bar_neg(foo& x)
{
  make_neg(boost::tie(x.a, x.b, x.c, x.d, x.e, x.f, x.g, x.h, x.i, x.j));
}

void baz_neg(foo& x)
{
  x.a = -x.a;
  x.b = -x.b;
  x.c = -x.c;
  x.d = -x.d;
  x.e = -x.e;
  x.f = -x.f;
  x.g = -x.g;
  x.h = -x.h;
  x.i = -x.i;
  x.j = -x.j;
}

Re: [RFC] Contributing tree-ssa to mainline

[Richard Kenner]

    If we want to develop a GCC 3.5 release without Tree-SSA, then we
    should have specific, non-SSA feature goals that we want to
    accomplish.  Otherwise, what is the benefit of GCC 3.5 over additional
    point releases of GCC 3.4 stable branch?

I don't understand your point.  Since GCC is a volunteer project, there is
no practical way of forming such "goals" or schedules.  We presume, unless
there's evidence to the contrary that people are going to be working on
improvements to GCC into the future.

If indeed a long period of time goes by without such improvements, it would
indeed be a good question about whether it would make sense to make a new
release before tree-ssa is ready, but I don't see how we can have any data
to make such a determination *now*.

Re: [RFC] Contributing tree-ssa to mainline

[Richard Kenner]

    Realistically, if we are going to make tree-ssa a complete non-starter
    because the Ada front-end isn't going to work and its maintainers are
    not showing any willingness to put forth the effort to make it work
    with already existing infrastructure, then, well, why bother with
    tree-ssa at all.

I've seen *nobody* from the Ada community advocating that.  Indeed both
Robert and I feel strongly that Ada's being behind should not be a relevant
criteria for tree-ssa inclusion.  So you have a strawman here.

Re: [RFC] Contributing tree-ssa to mainline

[Richard Kenner]

    If we are to wait for all the possible optimizations (vectorization,
    memory hierarchy, loop transformations, etc) to be contributed, we may
    have to wait quite a bit longer than if we included the infrastructure
    in mainline.

My threshold wouldn't be "all possible optimizations", but enough of
them to show that the new infrastructure not only is going to meet its
expectations but that it isn't going to need to continue to evolve in
major ways.

To me, merely saying that "this is obviously a better approach since
it's more modern and is what the textbooks show" would be a *disadvantage*
of the approach.  We need to see evidence that this approach really is better.

    By its very nature, mainline attracts quite a bit more development than
    an obscure branch.

I don't think anybody would call tree-ssa an "obscure branch".

Re: [RFC] Contributing tree-ssa to mainline

[Richard Kenner]

    Tree SSA has always been very conventional.  If I had wanted to do
    research, I would have started with my Concurrent SSA work.

What I meant is that there were significant details, such as the ordering
of lowering and optimizations (which optimizations should be done at which
level) and issues such as the replacability of the RTL optimizers, that
could not be known at the start of the project and that a large part of
the project is not implementing such decisions but figuring out what they
should be using an experimental approach.

Also, there is usually significant difference between textbooks and real
life so that trying to implement algorithms from a text into a real compiler
can itself be more in the research than straightforward development arena.

Re: [RFC] Contributing tree-ssa to mainline

[John R. Shannon]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Saturday 17 January 2004 05:07 am, Robert Dewar wrote:
> law@redhat.com wrote:
> > In message <10401170230.AA15232@vlsi1.ultra.nyu.edu>, Richard Kenner
> > writes:
> >
> > Given the lack of movement on that front, how can we realistically expect
> > any movement on something like tree-ssa?  Particularly when tree-ssa
> > depends on function at a time mode?
> >
> > Given the lack of movement from the Ada maintainers on that front, can we
> > realistically consider the Ada front-end even maintained, except perhaps
> > in a bugfix mode?

As an Ada user, and one following the 3.4 tree, I have to disagree about no 
movement on the Ada front. The code is under development. The changes from 
3.3.2 are significant.

P.S.: gcc 3.4 Ada builds under NetBSD-CURRENT on Ix86. Current 8 errors (none 
in tasking) from check Ada.
- -- 

John R. Shannon
john@johnrshannon.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (NetBSD)

iEYEARECAAYFAkAJJ1UACgkQOKbCxya4HYtW0QCgl2wFzA0twvAB8JwYeslWqvtT
QtgAn3ak7KBz9iKcSP8zhvUNwt7nbs55
=a0/p
-----END PGP SIGNATURE-----

Re: [RFC] Contributing tree-ssa to mainline

[Robert Dewar]

law@redhat.com wrote:
> In message <10401170230.AA15232@vlsi1.ultra.nyu.edu>, Richard Kenner writes:

> Given the lack of movement on that front, how can we realistically expect
> any movement on something like tree-ssa?  Particularly when tree-ssa
> depends on function at a time mode?
> 
> Given the lack of movement from the Ada maintainers on that front, can we
> realistically consider the Ada front-end even maintained, except perhaps
> in a bugfix mode?

Well in practice there is a huge amount of development on the Ada front
end, probably as much or more than any other gcc front end. It is really
a question of priorities. We don't have any Ada users for whom function
at a time is an important issue, where as there are a heap of other
important and urgent enhancements. So that tends to make function at a 
time non-urgent, even if of course important in the long run. Even in
the area of performance, for Ada users concerned with code quality, the
important issues are not in general optimization of the back end, but
rather Ada specific issues (e.g. efficient handling of multi-dimensional
packed arrays).

I agree with Richard, it is not that serious a problem if there is a lag
and Ada is unavailable for a while. That unavailability would in fact 
obviously create an increased urgency for getting function at a time to
work for Ada. After all, for years, GNAT users were successfully using
GCC 2.8 and it took quite a long time to get GNAT working with GCC 3.
We are now over that bump, and no doubt function at a time will be
achieved relatively soon. We can't commit a definite schedule (since
projects urgently needed by (and funded by) our customers will take
priority and can preempt non-funded projects, but that does not mean
that the non-funded projects don't eventually get done.

If the arguments for including tree-ssa are strong enough, my viewpoint 
would be that there is no need to let Ada be a blocking issue.

Re: [RFC] Contributing tree-ssa to mainline

[Diego Novillo]

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

On Sat, 2004-01-17 at 00:52, Per Bothner wrote:
> Diego Novillo wrote:
> 
> > On Fri, 2004-01-16 at 22:24, Richard Kenner wrote:
> > 
> > 
> >>Remember that the last time we had the discussion of the timing of tree-ssa,
> >>people claimed it was "essential" for 3.5 since there was a tremendous
> >>improvement on some C++ cases.  So let's see those cases.
> >>
> > 
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12747
> 
> Can you give numbers?  I.e. how much faster does that (or a similar)
> testcase run?
>
Sure.  I added some of the missing bits in 12747's test program to make
it executable (attached).  The binary produced by mainline executes in
28.62 seconds.  The one produced by tree-ssa executes in 10.57 seconds
(average over 3 runs).

As with any benchmark, the fact that we do good here cannot be
extrapolated to any other random piece of code.

[ apologies to our C++ experts for butchering the test case. ]


Diego.

[-- Attachment #2: 12747.C --]
[-- Type: text/x-c++, Size: 2039 bytes --]

#include <string.h>
#include <stdlib.h>

class BitRef;

class BitVector
{
public:

    BitVector (unsigned nbits) : m_size(nbits)
      {
	m_data = (unsigned long *)malloc (m_size*sizeof(unsigned long));
      }

    BitVector (const BitVector &orig) : m_size (orig.size())
      {
	m_data = (unsigned long *)malloc (m_size*sizeof(unsigned long));
	memcpy(m_data,orig.m_data,m_size);
      }

    BitVector & operator= (const BitVector &orig)
      {
	m_size = orig.size();
	m_data = (unsigned long *)malloc (m_size*sizeof(unsigned long));
	memcpy(m_data,orig.m_data,m_size);
      }

   ~BitVector ()
     {
       free (m_data);
     }
  unsigned size () const
  {
    return m_size;
  }
  bool getBit (unsigned idx)
    {
      return m_data[idx] != 0;
    }

  void setBit (unsigned idx, bool value)
    {
      m_data[idx] = (unsigned long)value;
    }

  inline BitRef operator[] (unsigned idx);
//private:
  unsigned long *m_data;
  unsigned m_size;
};

class BitRef
{
public:
  BitRef (BitVector & bv, unsigned idx):m_bv (bv), m_idx (idx)
  {
  }
  bool value () const
  {
    return m_bv.getBit (m_idx);
  }
  operator  bool () const
  {
    return value ();
  }
  BitRef & operator= (bool newVal)
  {
    m_bv.setBit (m_idx, newVal);
    return *this;
  }
  BitRef & operator= (const BitRef & newVal)
  {
    m_bv.setBit (m_idx, newVal.value ());
    return *this;
  }
private:
  BitVector & m_bv;
  unsigned m_idx;
};

inline BitRef
BitVector::operator[] (unsigned idx)
{
  return BitRef (*this, idx);
}

// abstract copy: compiler should be able to make this as fast as copy_2
void
copy (BitVector & dest, BitVector & src)
{
  unsigned
    sz = dest.size ();
  for (unsigned i = 0; i < sz; i++)
    dest[i] = src[i];
}

// direct copy, without proxy objects.
void
copy_2 (BitVector & dest, BitVector & src)
{
  unsigned
    sz = dest.size ();
  for (unsigned i = 0; i < sz; i++)
    dest.setBit (i, src.getBit (i));
}

main()
{
  BitVector bv1(30000), bv2(30000);
  int i;

  for (i = 0; i < 50000; i++)
    copy (bv1, bv2);
}

Re: [RFC] Contributing tree-ssa to mainline

[David Edelsohn]

	Agreeing with Roger, we don't know how to close the performance
gap using the RTL-only infrastructure, but we do see how an SSA
infrastructure can improve performance.

	Merging Tree-SSA into the trunk for GCC 3.5 does not mean (or
should not mean) merging it and then immediately branching for a release.
We do not need to achieve the release target performance at the point of
the merge.

	If we want to develop a GCC 3.5 release without Tree-SSA, then we
should have specific, non-SSA feature goals that we want to accomplish.
Otherwise, what is the benefit of GCC 3.5 over additional point releases
of GCC 3.4 stable branch?

David

Re: [RFC] Contributing tree-ssa to mainline

[law]

In message <10401170230.AA15232@vlsi1.ultra.nyu.edu>, Richard Kenner writes:
 >    First and foremost is the obvious question of whether people think that
 >    the whole infrastructure is worth adding to GCC at all.  From what we've
 >    discussed in the past few months, the consensus seems to be that it is. 
 >    But I think it's important to find out if folks think otherwise.
 >
 >    If we decide to add SSA for 3.5, then we need to determine exactly how
 >    we are going to go about it.
 >
 >My view is that I don't see this as something we can schedule (or even
 >decide) in advance.
 >
 >As I said, I see the nature of the tree-ssa project as research rather than
 >development.  Nobody seemed to understand what I meant before, so let me
 >clarify because it's part of my answer to how I view the above issues.
OK.  Let's take everything you've said as a given and let's ponder what
actually has been done with Ada to make it work with already existing
infrastructure mainline.  Specifically function at a time mode.  We've had
function at a time mode for a few years now, but yet we still have seen
little movement in the Ada front-end to support that mode.

Given the lack of movement on that front, how can we realistically expect
any movement on something like tree-ssa?  Particularly when tree-ssa
depends on function at a time mode?

Given the lack of movement from the Ada maintainers on that front, can we
realistically consider the Ada front-end even maintained, except perhaps
in a bugfix mode?

Realistically, if we are going to make tree-ssa a complete non-starter
because the Ada front-end isn't going to work and its maintainers are
not showing any willingness to put forth the effort to make it work with
already existing infrastructure, then, well, why bother with tree-ssa
at all.  I'll take my time and effort to some other non-GCC project
where I can actually make a difference.

Jeff

Re: [RFC] Contributing tree-ssa to mainline

[Andrew Pinski]

On Jan 16, 2004, at 21:52, Per Bothner wrote:

> Diego Novillo wrote:
>
>> On Fri, 2004-01-16 at 22:24, Richard Kenner wrote:
>>> Remember that the last time we had the discussion of the timing of 
>>> tree-ssa,
>>> people claimed it was "essential" for 3.5 since there was a 
>>> tremendous
>>> improvement on some C++ cases.  So let's see those cases.
>>>
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12747
>
> Can you give numbers?  I.e. how much faster does that (or a similar)
> testcase run?  Have we met Kenner's 2x goal?

First it also improves C code also.
See PR 9540 for an example
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9540

And PR 2806 for an example where the if combiner on the tree-ssa
beats the heck out of the one on the RTL level.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2806

Also PR 9566 where the problem is that GCC will put things on the stack 
too early.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9566

These can be any were between .5x and 10x depending on how big the 
struct is and if you
have large number of copies.

Also compile time for some testcases are much better, see PR 2692 for 
an example:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2692

Also the stack sizes that most function needs is going be lowered by a 
significant amount in
most C++ cases.  There are many test cases in the bugzilla for this.

I think the tree-ssa is in good shape to be included in for 3.5 except 
for the current
problem of bootstrapping on some targets/building for some targets, 
these really should be
fixed before the merging should happen.

Thanks,
Andrew Pinski

Re: [RFC] Contributing tree-ssa to mainline

[Roger Sayle]

On Sat, 17 Jan 2004, Diego Novillo wrote:
> On Fri, 2004-01-16 at 23:19, Roger Sayle wrote:
> > For years I've (we've) been trying to break this glass ceiling.  Why is
> > is that impressive optimization passes do little to make up the short
> > fall.  Is it because they have partial dead-code elimination and we don't,
> > or that they can apply synthetic multiplication later, or that they have
> > better reassociation...  Intel's vectorization would be nice...
> >
> Those things are either planned or being worked on.  As I said before,
> we need to balance pros and cons.
>
> If we are to wait for all the possible optimizations (vectorization,
> memory hierarchy, loop transformations, etc) to be contributed, we may
> have to wait quite a bit longer than if we included the infrastructure
> in mainline.

Sorry, my comments weren't meant as a list of prerequsistes of passes
to be implemented in tree-ssa before it get considered for integration.
Rather to refute the argument that both mainline and tree-ssa are already
close to their potential performance limits.

I'm fully aware that there a numerous pending optimizations that can
be made using the new tree-ssa infrastructure.  It is this *potential*
for improvement that should be included in the PROs for the branch.
In the last two years, your and Andreas' SPEC testing have shown that
mainline has barely improved 10 points on SPECint.  Given that the
tree-ssa has jumped over 10 points in the last six months, and that
there's clearly more to come, then even if all other factors were equal,
it would make sense to vote for the more dynamic of the two.


[This e-mail may contain forward looking statements.  Performance
benchmarks and compile-times can go up as well as down.  Past
performance is no guarantee or indicator of future events.  :>]

Roger
--

Re: [RFC] Contributing tree-ssa to mainline

[Per Bothner]

Diego Novillo wrote:

> On Fri, 2004-01-16 at 22:24, Richard Kenner wrote:
> 
> 
>>Remember that the last time we had the discussion of the timing of tree-ssa,
>>people claimed it was "essential" for 3.5 since there was a tremendous
>>improvement on some C++ cases.  So let's see those cases.
>>
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12747

Can you give numbers?  I.e. how much faster does that (or a similar)
testcase run?  Have we met Kenner's 2x goal?
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

Re: [RFC] Contributing tree-ssa to mainline

[Diego Novillo]

On Fri, 2004-01-16 at 23:19, Roger Sayle wrote:

> For years I've (we've) been trying to break this glass ceiling.  Why is
> is that impressive optimization passes do little to make up the short
> fall.  Is it because they have partial dead-code elimination and we don't,
> or that they can apply synthetic multiplication later, or that they have
> better reassociation...  Intel's vectorization would be nice...
> 
Those things are either planned or being worked on.  As I said before,
we need to balance pros and cons.

If we are to wait for all the possible optimizations (vectorization,
memory hierarchy, loop transformations, etc) to be contributed, we may
have to wait quite a bit longer than if we included the infrastructure
in mainline.

By its very nature, mainline attracts quite a bit more development than
an obscure branch.


Diego.

Re: [RFC] Contributing tree-ssa to mainline

[Diego Novillo]

On Fri, 2004-01-16 at 21:30, Richard Kenner wrote:

> In conventional software development (say for a game, avionics, or a linker),
> you have a specification and well-defined process for taking that
> specification and turning it into code.  You have a quite good idea when you
> start how things are going to go and there are simple metrics for seeing how
> far you are in the process.
> 
Tree SSA has always been very conventional.  If I had wanted to do
research, I would have started with my Concurrent SSA work.

The metrics and specifications have always been documented in the
project's web page (http://gcc.gnu.org/projects/tree-ssa/).  Also, see
the papers I presented last year at Nordu2003 and GCC Summit.

I agree that some of the goals have only partially been met.  Hence my
RFC to gather feedback from the community and weigh the pros and cons of
merging into mainline at this stage.

The discussion is also useful to discuss the status of the work in
detail, as well.  As Kaveh pointed out, I failed to provide several
details that I was just taking for granted.


Diego.

Re: [RFC] Contributing tree-ssa to mainline

[Roger Sayle]

On Sat, 17 Jan 2004, Steven Bosscher wrote:
> On Saturday 17 January 2004 03:30, Richard Kenner wrote:
> > My feeling is that "success" would be in showing at least one class of code
> > where we see very significantly better code (at least a factor of two) and
> > we see significant (around 10-20%) performance improvement in a larger
> > class of test cases.
>
> You must be joking.  I've added this beautiful quip to bugzilla:
>
> Moore's Law: "Advances in hardware double computing power every 18 months".
> Proebsting's law: "Advances in compiler optimizations double computing
> power every 18 years".
>
> Expecting tree-ssa to produce code better by a factor of two is simply
> unreasonable.


Whilst I agree that expecting a factor of two is asking for miracles,
there are clearly significant gains to be made without pushing the
envelope of current compiler theory.

My greatest disappointment working on GCC's optimizations, is that
try as I might I've only ever been able to push Andreas' SPECcpu2000
benchmarks perhaps a percentage point or two higher.  This on a platform
where Microsoft's compilers score about 20% higher.  Intel similarly
claims about 20% better performance than GCC on average.

For years I've (we've) been trying to break this glass ceiling.  Why is
is that impressive optimization passes do little to make up the short
fall.  Is it because they have partial dead-code elimination and we don't,
or that they can apply synthetic multiplication later, or that they have
better reassociation...  Intel's vectorization would be nice...

My assumption, and presumably I'm not alone, was that this was caused
to some extent by GCC's aging (inferior) infrastructure, and to a lesser
extend its requirement to support multiple targets rather be master of
one.  My great hope for tree-ssa was (and still is) that it'd tackle this
barrier.  Even half way there, 10% SPECint2000 on average would be good
and in theory achievable without braking Proebsting's law.


As I've mentioned before, one of the criteria that should be used in
assessing tree-ssa is its rate of improvement.  Deciding the fate of
tree-ssa at the first opportunity it becomes comparable with mainline,
by definition, becomes a difficult task.   If in a few weeks or months,
there's a clear 8% or 15% advantage to the branch, many of the
difficult issues we're struggling with today will be moot.  Of course,
if tree-ssa can't break out of the rut, I'll have to give some more
thought to what I hope to achieve with my life...

Roger
--

Re: [RFC] Contributing tree-ssa to mainline

[Diego Novillo]

On Fri, 2004-01-16 at 22:24, Richard Kenner wrote:

> Remember that the last time we had the discussion of the timing of tree-ssa,
> people claimed it was "essential" for 3.5 since there was a tremendous
> improvement on some C++ cases.  So let's see those cases.
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12747


Diego.

Re: [RFC] Contributing tree-ssa to mainline

[Richard Kenner]

    I think a few percentage, or even nothing at all, is significant
    because of the new infrastructure that's added, and the possibilities
    that it opens up.  That should also be taken into consideration.

Sure, but in that situation I feel it should stay in a branch until those
"possibilities" have indeed been "opened up".  Otherwise, it's a lot of
extra code to maintain and overhead to pay for in compilation without any
known benefit.  Newer is not always better.  Indeed I find that for most
of the products I buy, the quality is often *far* worse than that of the
same product purchased decades ago.

Whether or not (and to what extent) the tree-ssa infrastructure is
"significant" can't be made by arguments over possibilities it might open
up, but by demonstrating those possibilities.

Re: [RFC] Contributing tree-ssa to mainline

[Richard Kenner]

    Expecting tree-ssa to produce code better by a factor of two is simply
    unreasonable.

In general, of course.  But if it is really allowing new classes of
optimizations to be performed (which was the argument to justify the new
infrastructure), it should be possible to construct test cases that show
that sort of performance improvement (factors of two or more).

Remember that the last time we had the discussion of the timing of tree-ssa,
people claimed it was "essential" for 3.5 since there was a tremendous
improvement on some C++ cases.  So let's see those cases.

Re: [RFC] Contributing tree-ssa to mainline

[Diego Novillo]

On Fri, 2004-01-16 at 22:11, Steven Bosscher wrote:
> On Saturday 17 January 2004 03:58, Richard Kenner wrote:
> >     I would agree with you on principle.  But nobody is willing/able to
> >     update g77, and for Ada, everyone knows Kenner has done some work in
> >     this area but it's just not there and hasn't been for four years. So
> >     do you think we should wait until someone cares enough to make this
> >     transition?
> >
> > I'm curious where the "four years" come from.  GNAT has been around
> > for roughly ten years, but work on integrating it with GCC 3 (the only
> > version for which function-at-a-time makes sense) was just starting up
> > about 2.5 years ago.
> 
> The "four years" come from Diego.  That much time has past since he
> posted his first experimental tree-ssa patch.  I have to admit though
> that no-one could foresee back then what that patch would lead to...
> 
Three years, actually.  IIRC, I posted the initial implementation in
February 2001.


Diego.

Re: [RFC] Contributing tree-ssa to mainline

[Robert Dewar]

> Moore's Law: "Advances in hardware double computing power every 18 months".
> Proebsting's law: "Advances in compiler optimizations double computing
> power every 18 years".

That's actually a fairly optimistic position. I gave a talk at the compiler
conference some years ago on the subject of how successful advanced research
had been in slowing down compilers :-)

Re: [RFC] Contributing tree-ssa to mainline

[Steven Bosscher]

On Saturday 17 January 2004 03:58, Richard Kenner wrote:
>     I would agree with you on principle.  But nobody is willing/able to
>     update g77, and for Ada, everyone knows Kenner has done some work in
>     this area but it's just not there and hasn't been for four years. So
>     do you think we should wait until someone cares enough to make this
>     transition?
>
> I'm curious where the "four years" come from.  GNAT has been around
> for roughly ten years, but work on integrating it with GCC 3 (the only
> version for which function-at-a-time makes sense) was just starting up
> about 2.5 years ago.

The "four years" come from Diego.  That much time has past since he
posted his first experimental tree-ssa patch.  I have to admit though
that no-one could foresee back then what that patch would lead to...

Gr.
Steven

Re: [RFC] Contributing tree-ssa to mainline

[Steven Bosscher]

On Saturday 17 January 2004 03:54, Richard Kenner wrote:
>     Feel free to disagree with me.  But remember, they (tree-ssa
>     advocates) promised a lot.  If it turns out to be just a different
>     infrastructure, as opposed to a better one, I wouldn't feel the same.
>
> Again, agreed.  Major changes require major benefits: if all we end up
> doing is seeing a few percentage points either way, the tree-ssa project
> will have been a failure.

I think a few percentage, or even nothing at all, is significant
because of the new infrastructure that's added, and the possibilities
that it opens up.  That should also be taken into consideration.

Gr.
Steven

Re: [RFC] Contributing tree-ssa to mainline

[Steven Bosscher]

On Saturday 17 January 2004 03:30, Richard Kenner wrote:
> My feeling is that "success" would be in showing at least one class of code
> where we see very significantly better code (at least a factor of two) and
> we see significant (around 10-20%) performance improvement in a larger
> class of test cases.

You must be joking.  I've added this beautiful quip to bugzilla:

Moore's Law: "Advances in hardware double computing power every 18 months".
Proebsting's law: "Advances in compiler optimizations double computing
power every 18 years".

Expecting tree-ssa to produce code better by a factor of two is simply
unreasonable.

Gr.
Steven

Re: [RFC] Contributing tree-ssa to mainline

[Robert Dewar]

Richard Kenner wrote:

> At some point in the not too distant future, the Ada front end will handle
> function-at-a-time and then converting it to using tree-ssa might be
> something that the tree-ssa folks can either do or help with, but I don't see
> this is a major timing issue: even if we had one release of GCC (say 3.5)
> that didn't support Ada, it wouldn't be fatal and should not hold up tree-ssa
> if it were ready before the Ada conversion was done.

I entirely agree with Richard's assessment here.

Re: [RFC] Contributing tree-ssa to mainline

[Richard Kenner]

    I would agree with you on principle.  But nobody is willing/able to
    update g77, and for Ada, everyone knows Kenner has done some work in
    this area but it's just not there and hasn't been for four years. So
    do you think we should wait until someone cares enough to make this
    transition?

I'm curious where the "four years" come from.  GNAT has been around
for roughly ten years, but work on integrating it with GCC 3 (the only
version for which function-at-a-time makes sense) was just starting up
about 2.5 years ago.

Re: [RFC] Contributing tree-ssa to mainline

[Richard Kenner]

    My feeling on this matter is purely in the context of all those
    goodies promised.  If the new infrastructure is really that good, and
    we all agree this is the "future" of GCC, I can live with some
    frontends not working and asking it's community to pitch in and
    upgrade it.

That's the way I see it as well.  I see the only relevant timing issue
as being when the new infrastructure shows its desirability and
stability by being able to host the new classes of optimizations that
it was designed for.  If it does, we can live with some frontends not
working and even some regressions because major changes should be permitted
to cause some disruptions as they are being completed.

    Feel free to disagree with me.  But remember, they (tree-ssa
    advocates) promised a lot.  If it turns out to be just a different
    infrastructure, as opposed to a better one, I wouldn't feel the same.

Again, agreed.  Major changes require major benefits: if all we end up doing
is seeing a few percentage points either way, the tree-ssa project will have
been a failure.

Re: [RFC] Contributing tree-ssa to mainline

[Richard Kenner]

    > As it is today, it is impossible to build an Ada compiler with the
    > branch.

    I'm afraid that's a blocker.

I disagree.  If every other criteria is met, I don't see that as a blocking
issue, mostly because that's not a "fault" of the tree-ssa project and it
would be unfair to hold them up while that work is being done.

At some point in the not too distant future, the Ada front end will handle
function-at-a-time and then converting it to using tree-ssa might be
something that the tree-ssa folks can either do or help with, but I don't see
this is a major timing issue: even if we had one release of GCC (say 3.5)
that didn't support Ada, it wouldn't be fatal and should not hold up tree-ssa
if it were ready before the Ada conversion was done.

Re: [RFC] Contributing tree-ssa to mainline

[Richard Kenner]

    First and foremost is the obvious question of whether people think that
    the whole infrastructure is worth adding to GCC at all.  From what we've
    discussed in the past few months, the consensus seems to be that it is. 
    But I think it's important to find out if folks think otherwise.

    If we decide to add SSA for 3.5, then we need to determine exactly how
    we are going to go about it.

My view is that I don't see this as something we can schedule (or even
decide) in advance.

As I said, I see the nature of the tree-ssa project as research rather than
development.  Nobody seemed to understand what I meant before, so let me
clarify because it's part of my answer to how I view the above issues.

In conventional software development (say for a game, avionics, or a linker),
you have a specification and well-defined process for taking that
specification and turning it into code.  You have a quite good idea when you
start how things are going to go and there are simple metrics for seeing how
far you are in the process.

In contrast, in a research project, what you start with is more a goal than a
specification.  You usually have an idea of how you're going about achieving
that goal, but the bulk of the project is in fleshing out the details of how
to achieve the goal rather than a straightforward programming project.  When
you start the project, you don't know in advance how things will go in detail
or even if you'll be able to achieve the goal.  There's usually no simple way
of seeing how far you've gotten in the project because of the lack of a good
metric: a long time may go by with no progress towards that goal or there
might be a "eureka moment" when great progress is made suddenly.

So I don't think we can or should ever answer in advance the question of when
(or even if) the tree-ssa branch will be ready, but instead work on defining
what criteria we'll use for making that determination.

In my mind, part of that criteria would be the transition of the work from
research to more conventional development, which means that it has passed the
experimental stages where people are seeing what does and doesn't work and
what works best.  But most important in my mind is having the work meet it's
goal.  So the question then becomes what *is* that goal.

Obviously, it's up to the people working on the project to clearly state what
they see as the goal and perhaps provide metrics to see if it's being met,
but roughly speaking I see the goal as making major improvements in
optimization by setting up an infrastructure for doing optimizations at a
high level.  I do *not* see the setting up of that infrastructure as itself a
useful benchmark: it needs to be shown that it actually *helps*.

The issue of whether or not the RTL optimizers can be eliminated or
simplified has been discussed a lot.  One argument would be that we should be
able to answer those questions before considering tree-ssa to be
"operational", but I'm not sure how strong an argument that is.

From a performance point of view, if all we do is *add* more optimizers
rather than replace some, the burden on those optimizers is higher since they
will increase compilation time.  On the other hand, doing more optimization
earlier will speed up the RTL optimizers by giving them less to work with, so
the strength of that concern is yet to be demonstrated.

My feeling is that "success" would be in showing at least one class of code
where we see very significantly better code (at least a factor of two) and we
see significant (around 10-20%) performance improvement in a larger class of
test cases.  If we leave the RTL optimizers in place, then we should *always*
be producing better code than without tree-ssa: any situation where we don't
strikes me as demonstrating something fundamental that needs more work; if we
replace some RTL optimizers, then I can see relaxing this standard if we see
our way to fixing those performance regressions without major redesign.  I
don't see compilation performace as being a major driver here unless it's a
major degradation.

I understand that the longer we keep the separate branch the more maintenance
cost we have, but the opposite error would be far worse: if it turns out that
the tree-ssa approach is not achieving its goal and we decide to
significantly postpone it (or even that it's not viable), backing it out in
the presence of lots of other unrelated work being put into the tree is a
*very* difficult prospect.  So I'd argue for a very conservative criteria for
merging it into the mainline.