[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

[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

[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

[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

[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>

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

[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

[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

[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

[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]

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

[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: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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

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

[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

[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

[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, 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

[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

[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

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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

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]

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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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 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

[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