* [RFC] Contributing tree-ssa to mainline @ 2004-01-17 0:19 Diego Novillo 2004-01-17 0:31 ` Daniel Berlin ` (6 more replies) 0 siblings, 7 replies; 86+ messages in thread From: Diego Novillo @ 2004-01-17 0:19 UTC (permalink / raw) To: gcc 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. ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-17 0:19 [RFC] Contributing tree-ssa to mainline Diego Novillo @ 2004-01-17 0:31 ` Daniel Berlin 2004-01-17 0:35 ` Andrew Pinski ` (5 subsequent siblings) 6 siblings, 0 replies; 86+ messages in thread From: Daniel Berlin @ 2004-01-17 0:31 UTC (permalink / raw) To: Diego Novillo; +Cc: gcc > 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 ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-17 0:19 [RFC] Contributing tree-ssa to mainline Diego Novillo 2004-01-17 0:31 ` Daniel Berlin @ 2004-01-17 0:35 ` Andrew Pinski 2004-01-17 0:44 ` Gerald Pfeifer ` (4 subsequent siblings) 6 siblings, 0 replies; 86+ messages in thread From: Andrew Pinski @ 2004-01-17 0:35 UTC (permalink / raw) To: Diego Novillo; +Cc: gcc, 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 ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-17 0:19 [RFC] Contributing tree-ssa to mainline Diego Novillo 2004-01-17 0:31 ` Daniel Berlin 2004-01-17 0:35 ` Andrew Pinski @ 2004-01-17 0:44 ` Gerald Pfeifer 2004-01-17 0:53 ` law ` (4 more replies) 2004-01-17 11:08 ` Andrew Walrond ` (3 subsequent siblings) 6 siblings, 5 replies; 86+ messages in thread From: Gerald Pfeifer @ 2004-01-17 0:44 UTC (permalink / raw) To: Diego Novillo; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-17 0:44 ` Gerald Pfeifer @ 2004-01-17 0:53 ` law 2004-01-17 0:54 ` law ` (3 subsequent siblings) 4 siblings, 0 replies; 86+ messages in thread From: law @ 2004-01-17 0:53 UTC (permalink / raw) To: Gerald Pfeifer; +Cc: Diego Novillo, gcc 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 ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-17 0:44 ` Gerald Pfeifer 2004-01-17 0:53 ` law @ 2004-01-17 0:54 ` law 2004-01-17 1:37 ` Gerald Pfeifer 2004-01-17 0:55 ` Eric Christopher ` (2 subsequent siblings) 4 siblings, 1 reply; 86+ messages in thread From: law @ 2004-01-17 0:54 UTC (permalink / raw) To: Gerald Pfeifer; +Cc: Diego Novillo, gcc 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 ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-17 0:54 ` law @ 2004-01-17 1:37 ` Gerald Pfeifer 2004-01-17 1:46 ` Diego Novillo 0 siblings, 1 reply; 86+ messages in thread From: Gerald Pfeifer @ 2004-01-17 1:37 UTC (permalink / raw) To: Jeffrey Law; +Cc: Diego Novillo, gcc 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 ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-17 1:37 ` Gerald Pfeifer @ 2004-01-17 1:46 ` Diego Novillo 0 siblings, 0 replies; 86+ messages in thread From: Diego Novillo @ 2004-01-17 1:46 UTC (permalink / raw) To: Gerald Pfeifer; +Cc: Jeff Law, gcc 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. ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-17 0:44 ` Gerald Pfeifer 2004-01-17 0:53 ` law 2004-01-17 0:54 ` law @ 2004-01-17 0:55 ` Eric Christopher 2004-01-17 2:48 ` Robert Dewar 2004-01-17 1:02 ` Joseph S. Myers 2004-01-17 2:15 ` Steven Bosscher 4 siblings, 1 reply; 86+ messages in thread From: Eric Christopher @ 2004-01-17 0:55 UTC (permalink / raw) To: Gerald Pfeifer; +Cc: Diego Novillo, gcc > > 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> ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-17 0:55 ` Eric Christopher @ 2004-01-17 2:48 ` Robert Dewar 2004-01-17 22:08 ` Eric Christopher 0 siblings, 1 reply; 86+ messages in thread From: Robert Dewar @ 2004-01-17 2:48 UTC (permalink / raw) To: Eric Christopher; +Cc: Gerald Pfeifer, Diego Novillo, gcc 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. ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-17 2:48 ` Robert Dewar @ 2004-01-17 22:08 ` Eric Christopher 0 siblings, 0 replies; 86+ messages in thread From: Eric Christopher @ 2004-01-17 22:08 UTC (permalink / raw) To: Robert Dewar; +Cc: Gerald Pfeifer, Diego Novillo, gcc > 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> ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-17 0:44 ` Gerald Pfeifer ` (2 preceding siblings ...) 2004-01-17 0:55 ` Eric Christopher @ 2004-01-17 1:02 ` Joseph S. Myers 2004-01-17 1:51 ` Kaveh R. Ghazi 2004-01-17 5:31 ` Diego Novillo 2004-01-17 2:15 ` Steven Bosscher 4 siblings, 2 replies; 86+ messages in thread From: Joseph S. Myers @ 2004-01-17 1:02 UTC (permalink / raw) To: Gerald Pfeifer; +Cc: Diego Novillo, gcc 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 ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-17 1:02 ` Joseph S. Myers @ 2004-01-17 1:51 ` Kaveh R. Ghazi 2004-01-17 2:01 ` Gabriel Dos Reis 2004-01-17 3:36 ` Diego Novillo 2004-01-17 5:31 ` Diego Novillo 1 sibling, 2 replies; 86+ messages in thread From: Kaveh R. Ghazi @ 2004-01-17 1:51 UTC (permalink / raw) To: jsm; +Cc: dnovillo, gcc, gp, law > > > 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 ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-17 1:51 ` Kaveh R. Ghazi @ 2004-01-17 2:01 ` Gabriel Dos Reis 2004-01-17 2:17 ` Kaveh R. Ghazi 2004-01-17 2:19 ` Steven Bosscher 2004-01-17 3:36 ` Diego Novillo 1 sibling, 2 replies; 86+ messages in thread From: Gabriel Dos Reis @ 2004-01-17 2:01 UTC (permalink / raw) To: Kaveh R. Ghazi; +Cc: jsm, dnovillo, gcc, gp, law "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 ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-17 2:01 ` Gabriel Dos Reis @ 2004-01-17 2:17 ` Kaveh R. Ghazi 2004-01-17 3:01 ` Daniel Berlin 2004-01-17 2:19 ` Steven Bosscher 1 sibling, 1 reply; 86+ messages in thread From: Kaveh R. Ghazi @ 2004-01-17 2:17 UTC (permalink / raw) To: gdr; +Cc: dnovillo, gcc, gp, jsm, law > 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 ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-17 2:17 ` Kaveh R. Ghazi @ 2004-01-17 3:01 ` Daniel Berlin 0 siblings, 0 replies; 86+ messages in thread From: Daniel Berlin @ 2004-01-17 3:01 UTC (permalink / raw) To: Kaveh R. Ghazi; +Cc: gp, law, dnovillo, gcc, gdr, jsm 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). ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-17 2:01 ` Gabriel Dos Reis 2004-01-17 2:17 ` Kaveh R. Ghazi @ 2004-01-17 2:19 ` Steven Bosscher 2004-01-17 3:02 ` Robert Dewar 1 sibling, 1 reply; 86+ messages in thread From: Steven Bosscher @ 2004-01-17 2:19 UTC (permalink / raw) To: Gabriel Dos Reis, Kaveh R. Ghazi; +Cc: jsm, dnovillo, gcc, gp, law 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 ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-17 2:19 ` Steven Bosscher @ 2004-01-17 3:02 ` Robert Dewar 2004-01-17 3:55 ` Andrew Pinski 0 siblings, 1 reply; 86+ messages in thread From: Robert Dewar @ 2004-01-17 3:02 UTC (permalink / raw) To: Steven Bosscher Cc: Gabriel Dos Reis, Kaveh R. Ghazi, jsm, dnovillo, gcc, gp, law 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. ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-17 3:02 ` Robert Dewar @ 2004-01-17 3:55 ` Andrew Pinski 0 siblings, 0 replies; 86+ messages in thread From: Andrew Pinski @ 2004-01-17 3:55 UTC (permalink / raw) To: Robert Dewar Cc: Andrew Pinski, gcc, Kaveh R. Ghazi, Gabriel Dos Reis, law, Steven Bosscher, gp, dnovillo, jsm 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 ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-17 1:51 ` Kaveh R. Ghazi 2004-01-17 2:01 ` Gabriel Dos Reis @ 2004-01-17 3:36 ` Diego Novillo 2004-01-17 13:06 ` Giovanni Bajo ` (3 more replies) 1 sibling, 4 replies; 86+ messages in thread From: Diego Novillo @ 2004-01-17 3:36 UTC (permalink / raw) To: Kaveh R. Ghazi; +Cc: jsm, gcc, gp, Jeff Law 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. ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-17 3:36 ` Diego Novillo @ 2004-01-17 13:06 ` Giovanni Bajo 2004-01-17 13:53 ` Jan Hubicka ` (2 subsequent siblings) 3 siblings, 0 replies; 86+ messages in thread From: Giovanni Bajo @ 2004-01-17 13:06 UTC (permalink / raw) To: Diego Novillo, Kaveh R. Ghazi; +Cc: jsm, gcc, gp, Jeff Law 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 ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-17 3:36 ` Diego Novillo 2004-01-17 13:06 ` Giovanni Bajo @ 2004-01-17 13:53 ` Jan Hubicka 2004-01-18 7:01 ` law 2004-01-17 17:04 ` Kaveh R. Ghazi 2004-01-17 17:12 ` Kaveh R. Ghazi 3 siblings, 1 reply; 86+ messages in thread From: Jan Hubicka @ 2004-01-17 13:53 UTC (permalink / raw) To: Diego Novillo; +Cc: Kaveh R. Ghazi, jsm, gcc, gp, Jeff Law > > 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 ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-17 13:53 ` Jan Hubicka @ 2004-01-18 7:01 ` law 0 siblings, 0 replies; 86+ messages in thread From: law @ 2004-01-18 7:01 UTC (permalink / raw) To: Jan Hubicka; +Cc: Diego Novillo, Kaveh R. Ghazi, jsm, gcc, gp 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 ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-17 3:36 ` Diego Novillo 2004-01-17 13:06 ` Giovanni Bajo 2004-01-17 13:53 ` Jan Hubicka @ 2004-01-17 17:04 ` Kaveh R. Ghazi 2004-01-17 17:16 ` Scott Robert Ladd ` (2 more replies) 2004-01-17 17:12 ` Kaveh R. Ghazi 3 siblings, 3 replies; 86+ messages in thread From: Kaveh R. Ghazi @ 2004-01-17 17:04 UTC (permalink / raw) To: dnovillo; +Cc: gcc, gp, jsm, law, mark, wilson > 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 ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-17 17:04 ` Kaveh R. Ghazi @ 2004-01-17 17:16 ` Scott Robert Ladd 2004-01-17 17:30 ` Kaveh R. Ghazi 2004-01-17 17:37 ` Robert Dewar 2004-01-17 18:06 ` Mark Mitchell 2004-01-18 7:15 ` law 2 siblings, 2 replies; 86+ messages in thread From: Scott Robert Ladd @ 2004-01-17 17:16 UTC (permalink / raw) To: Kaveh R. Ghazi, gcc mailing list 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 ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-17 17:16 ` Scott Robert Ladd @ 2004-01-17 17:30 ` Kaveh R. Ghazi 2004-01-17 17:50 ` Scott Robert Ladd 2004-01-17 17:37 ` Robert Dewar 1 sibling, 1 reply; 86+ messages in thread From: Kaveh R. Ghazi @ 2004-01-17 17:30 UTC (permalink / raw) To: coyote, gcc > 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 ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-17 17:30 ` Kaveh R. Ghazi @ 2004-01-17 17:50 ` Scott Robert Ladd 0 siblings, 0 replies; 86+ messages in thread From: Scott Robert Ladd @ 2004-01-17 17:50 UTC (permalink / raw) To: Kaveh R. Ghazi; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-17 17:16 ` Scott Robert Ladd 2004-01-17 17:30 ` Kaveh R. Ghazi @ 2004-01-17 17:37 ` Robert Dewar 2004-01-17 17:46 ` Joseph S. Myers 2004-01-17 17:58 ` Scott Robert Ladd 1 sibling, 2 replies; 86+ messages in thread From: Robert Dewar @ 2004-01-17 17:37 UTC (permalink / raw) To: Scott Robert Ladd; +Cc: Kaveh R. Ghazi, gcc mailing list 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. ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-17 17:37 ` Robert Dewar @ 2004-01-17 17:46 ` Joseph S. Myers 2004-01-17 17:51 ` Robert Dewar 2004-01-17 17:58 ` Scott Robert Ladd 1 sibling, 1 reply; 86+ messages in thread From: Joseph S. Myers @ 2004-01-17 17:46 UTC (permalink / raw) To: Robert Dewar; +Cc: gcc mailing list 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 ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-17 17:46 ` Joseph S. Myers @ 2004-01-17 17:51 ` Robert Dewar 2004-01-17 18:11 ` Joseph S. Myers 0 siblings, 1 reply; 86+ messages in thread From: Robert Dewar @ 2004-01-17 17:51 UTC (permalink / raw) To: Joseph S. Myers; +Cc: gcc mailing list 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. ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-17 17:51 ` Robert Dewar @ 2004-01-17 18:11 ` Joseph S. Myers 2004-01-17 19:12 ` Arnaud Charlet 2004-01-29 0:00 ` Robert Dewar 0 siblings, 2 replies; 86+ messages in thread From: Joseph S. Myers @ 2004-01-17 18:11 UTC (permalink / raw) To: Robert Dewar; +Cc: gcc mailing list 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 ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-17 18:11 ` Joseph S. Myers @ 2004-01-17 19:12 ` Arnaud Charlet 2004-01-19 12:19 ` Ada commits to branch (was: [RFC] Contributing tree-ssa to mainline) Laurent GUERBY 2004-01-29 0:36 ` [RFC] Contributing tree-ssa to mainline Robert Dewar 2004-01-29 0:00 ` Robert Dewar 1 sibling, 2 replies; 86+ messages in thread From: Arnaud Charlet @ 2004-01-17 19:12 UTC (permalink / raw) To: Joseph S. Myers; +Cc: Robert Dewar, gcc mailing list > 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 ^ permalink raw reply [flat|nested] 86+ messages in thread
* Ada commits to branch (was: [RFC] Contributing tree-ssa to mainline) 2004-01-17 19:12 ` Arnaud Charlet @ 2004-01-19 12:19 ` Laurent GUERBY 2004-01-19 12:23 ` Arnaud Charlet 2004-01-29 0:36 ` [RFC] Contributing tree-ssa to mainline Robert Dewar 1 sibling, 1 reply; 86+ messages in thread From: Laurent GUERBY @ 2004-01-19 12:19 UTC (permalink / raw) To: Arnaud Charlet; +Cc: Joseph S. Myers, Robert Dewar, gcc mailing list 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 ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: Ada commits to branch (was: [RFC] Contributing tree-ssa to mainline) 2004-01-19 12:19 ` Ada commits to branch (was: [RFC] Contributing tree-ssa to mainline) Laurent GUERBY @ 2004-01-19 12:23 ` Arnaud Charlet 2004-01-19 18:35 ` Laurent GUERBY 0 siblings, 1 reply; 86+ messages in thread From: Arnaud Charlet @ 2004-01-19 12:23 UTC (permalink / raw) To: Laurent GUERBY Cc: Arnaud Charlet, Joseph S. Myers, Robert Dewar, gcc mailing list > 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 ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: Ada commits to branch (was: [RFC] Contributing tree-ssa to mainline) 2004-01-19 12:23 ` Arnaud Charlet @ 2004-01-19 18:35 ` Laurent GUERBY 2004-01-19 22:11 ` Arnaud Charlet 0 siblings, 1 reply; 86+ messages in thread From: Laurent GUERBY @ 2004-01-19 18:35 UTC (permalink / raw) To: Arnaud Charlet; +Cc: Joseph S. Myers, Robert Dewar, gcc mailing list 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 ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: Ada commits to branch (was: [RFC] Contributing tree-ssa to mainline) 2004-01-19 18:35 ` Laurent GUERBY @ 2004-01-19 22:11 ` Arnaud Charlet 2004-01-19 22:22 ` Laurent GUERBY 0 siblings, 1 reply; 86+ messages in thread From: Arnaud Charlet @ 2004-01-19 22:11 UTC (permalink / raw) To: Laurent GUERBY Cc: Arnaud Charlet, Joseph S. Myers, Robert Dewar, gcc mailing list > 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 ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: Ada commits to branch (was: [RFC] Contributing tree-ssa to mainline) 2004-01-19 22:11 ` Arnaud Charlet @ 2004-01-19 22:22 ` Laurent GUERBY 0 siblings, 0 replies; 86+ messages in thread From: Laurent GUERBY @ 2004-01-19 22:22 UTC (permalink / raw) To: Arnaud Charlet; +Cc: Joseph S. Myers, Robert Dewar, gcc mailing list 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 ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-17 19:12 ` Arnaud Charlet 2004-01-19 12:19 ` Ada commits to branch (was: [RFC] Contributing tree-ssa to mainline) Laurent GUERBY @ 2004-01-29 0:36 ` Robert Dewar 1 sibling, 0 replies; 86+ messages in thread From: Robert Dewar @ 2004-01-29 0:36 UTC (permalink / raw) To: Arnaud Charlet; +Cc: Joseph S. Myers, gcc mailing list 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. ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-17 18:11 ` Joseph S. Myers 2004-01-17 19:12 ` Arnaud Charlet @ 2004-01-29 0:00 ` Robert Dewar 1 sibling, 0 replies; 86+ messages in thread From: Robert Dewar @ 2004-01-29 0:00 UTC (permalink / raw) To: Joseph S. Myers; +Cc: gcc mailing list > 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. ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-17 17:37 ` Robert Dewar 2004-01-17 17:46 ` Joseph S. Myers @ 2004-01-17 17:58 ` Scott Robert Ladd 2004-01-17 18:09 ` Joseph S. Myers 1 sibling, 1 reply; 86+ messages in thread From: Scott Robert Ladd @ 2004-01-17 17:58 UTC (permalink / raw) To: Robert Dewar, gcc mailing list 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 ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-17 17:58 ` Scott Robert Ladd @ 2004-01-17 18:09 ` Joseph S. Myers 0 siblings, 0 replies; 86+ messages in thread From: Joseph S. Myers @ 2004-01-17 18:09 UTC (permalink / raw) To: Scott Robert Ladd; +Cc: Robert Dewar, gcc mailing list 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 ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-17 17:04 ` Kaveh R. Ghazi 2004-01-17 17:16 ` Scott Robert Ladd @ 2004-01-17 18:06 ` Mark Mitchell 2004-01-18 7:15 ` law 2 siblings, 0 replies; 86+ messages in thread From: Mark Mitchell @ 2004-01-17 18:06 UTC (permalink / raw) To: Kaveh R. Ghazi; +Cc: dnovillo, gcc, gp, jsm, law, wilson > 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 ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-17 17:04 ` Kaveh R. Ghazi 2004-01-17 17:16 ` Scott Robert Ladd 2004-01-17 18:06 ` Mark Mitchell @ 2004-01-18 7:15 ` law 2004-01-18 15:50 ` Daniel Berlin 2 siblings, 1 reply; 86+ messages in thread From: law @ 2004-01-18 7:15 UTC (permalink / raw) To: Kaveh R. Ghazi; +Cc: dnovillo, gcc, gp, jsm, mark, wilson 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 ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-18 7:15 ` law @ 2004-01-18 15:50 ` Daniel Berlin 0 siblings, 0 replies; 86+ messages in thread From: Daniel Berlin @ 2004-01-18 15:50 UTC (permalink / raw) To: law; +Cc: gp, wilson, dnovillo, gcc, Kaveh R. Ghazi, mark, jsm > > 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 ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-17 3:36 ` Diego Novillo ` (2 preceding siblings ...) 2004-01-17 17:04 ` Kaveh R. Ghazi @ 2004-01-17 17:12 ` Kaveh R. Ghazi 2004-01-17 17:26 ` Diego Novillo 3 siblings, 1 reply; 86+ messages in thread From: Kaveh R. Ghazi @ 2004-01-17 17:12 UTC (permalink / raw) To: dnovillo; +Cc: gcc, gp, jsm, law > 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 ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-17 17:12 ` Kaveh R. Ghazi @ 2004-01-17 17:26 ` Diego Novillo 0 siblings, 0 replies; 86+ messages in thread From: Diego Novillo @ 2004-01-17 17:26 UTC (permalink / raw) To: Kaveh R. Ghazi; +Cc: gcc, gp, jsm, Jeff Law 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. ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-17 1:02 ` Joseph S. Myers 2004-01-17 1:51 ` Kaveh R. Ghazi @ 2004-01-17 5:31 ` Diego Novillo 2004-01-17 6:15 ` law 2004-01-17 11:16 ` Joseph S. Myers 1 sibling, 2 replies; 86+ messages in thread From: Diego Novillo @ 2004-01-17 5:31 UTC (permalink / raw) To: Joseph S. Myers; +Cc: Gerald Pfeifer, gcc 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. ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-17 5:31 ` Diego Novillo @ 2004-01-17 6:15 ` law 2004-01-17 6:22 ` Andrew Pinski ` (2 more replies) 2004-01-17 11:16 ` Joseph S. Myers 1 sibling, 3 replies; 86+ messages in thread From: law @ 2004-01-17 6:15 UTC (permalink / raw) To: Diego Novillo; +Cc: Joseph S. Myers, Gerald Pfeifer, gcc 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 ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-17 6:15 ` law @ 2004-01-17 6:22 ` Andrew Pinski 2004-01-17 6:38 ` Diego Novillo 2004-01-17 14:45 ` Daniel Berlin 2 siblings, 0 replies; 86+ messages in thread From: Andrew Pinski @ 2004-01-17 6:22 UTC (permalink / raw) To: law; +Cc: gcc, Gerald Pfeifer, Diego Novillo, Joseph S. Myers, 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 ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-17 6:15 ` law 2004-01-17 6:22 ` Andrew Pinski @ 2004-01-17 6:38 ` Diego Novillo 2004-01-17 14:45 ` Daniel Berlin 2 siblings, 0 replies; 86+ messages in thread From: Diego Novillo @ 2004-01-17 6:38 UTC (permalink / raw) To: Jeff Law; +Cc: Joseph S. Myers, Gerald Pfeifer, gcc 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. ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-17 6:15 ` law 2004-01-17 6:22 ` Andrew Pinski 2004-01-17 6:38 ` Diego Novillo @ 2004-01-17 14:45 ` Daniel Berlin 2004-01-17 21:23 ` law 2 siblings, 1 reply; 86+ messages in thread From: Daniel Berlin @ 2004-01-17 14:45 UTC (permalink / raw) To: law; +Cc: Diego Novillo, Gerald Pfeifer, gcc, Joseph S. Myers > 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. ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-17 14:45 ` Daniel Berlin @ 2004-01-17 21:23 ` law 2004-01-17 21:33 ` Steven Bosscher 0 siblings, 1 reply; 86+ messages in thread From: law @ 2004-01-17 21:23 UTC (permalink / raw) To: Daniel Berlin; +Cc: Diego Novillo, Gerald Pfeifer, gcc, Joseph S. Myers 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 ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-17 21:23 ` law @ 2004-01-17 21:33 ` Steven Bosscher 2004-01-18 2:34 ` Zack Weinberg 0 siblings, 1 reply; 86+ messages in thread From: Steven Bosscher @ 2004-01-17 21:33 UTC (permalink / raw) To: law, Daniel Berlin; +Cc: Diego Novillo, Gerald Pfeifer, gcc, Joseph S. Myers 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 ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-17 21:33 ` Steven Bosscher @ 2004-01-18 2:34 ` Zack Weinberg 0 siblings, 0 replies; 86+ messages in thread From: Zack Weinberg @ 2004-01-18 2:34 UTC (permalink / raw) To: Steven Bosscher Cc: law, Daniel Berlin, Diego Novillo, Gerald Pfeifer, gcc, Joseph S. Myers 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 ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-17 5:31 ` Diego Novillo 2004-01-17 6:15 ` law @ 2004-01-17 11:16 ` Joseph S. Myers 2004-01-17 17:50 ` Diego Novillo 2004-01-17 23:38 ` [RFC] Contributing tree-ssa to mainline Toon Moene 1 sibling, 2 replies; 86+ messages in thread From: Joseph S. Myers @ 2004-01-17 11:16 UTC (permalink / raw) To: Diego Novillo; +Cc: Gerald Pfeifer, gcc 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 ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-17 11:16 ` Joseph S. Myers @ 2004-01-17 17:50 ` Diego Novillo 2004-01-17 18:06 ` Joseph S. Myers 2004-01-17 20:14 ` Steven Bosscher 2004-01-17 23:38 ` [RFC] Contributing tree-ssa to mainline Toon Moene 1 sibling, 2 replies; 86+ messages in thread From: Diego Novillo @ 2004-01-17 17:50 UTC (permalink / raw) To: Joseph S. Myers; +Cc: Gerald Pfeifer, gcc 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. ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-17 17:50 ` Diego Novillo @ 2004-01-17 18:06 ` Joseph S. Myers 2004-01-17 20:14 ` Steven Bosscher 1 sibling, 0 replies; 86+ messages in thread From: Joseph S. Myers @ 2004-01-17 18:06 UTC (permalink / raw) To: Diego Novillo; +Cc: Gerald Pfeifer, gcc 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 ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-17 17:50 ` Diego Novillo 2004-01-17 18:06 ` Joseph S. Myers @ 2004-01-17 20:14 ` Steven Bosscher 2004-01-17 22:55 ` cfg.texi (was: [RFC] Contributing tree-ssa to mainline) Steven Bosscher 1 sibling, 1 reply; 86+ messages in thread From: Steven Bosscher @ 2004-01-17 20:14 UTC (permalink / raw) To: Diego Novillo, Joseph S. Myers; +Cc: Gerald Pfeifer, gcc 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 ^ permalink raw reply [flat|nested] 86+ messages in thread
* cfg.texi (was: [RFC] Contributing tree-ssa to mainline) 2004-01-17 20:14 ` Steven Bosscher @ 2004-01-17 22:55 ` Steven Bosscher 2004-01-17 22:58 ` Steven Bosscher 0 siblings, 1 reply; 86+ messages in thread From: Steven Bosscher @ 2004-01-17 22:55 UTC (permalink / raw) To: Diego Novillo, Joseph S. Myers, jh, gp; +Cc: gcc 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. ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: cfg.texi (was: [RFC] Contributing tree-ssa to mainline) 2004-01-17 22:55 ` cfg.texi (was: [RFC] Contributing tree-ssa to mainline) Steven Bosscher @ 2004-01-17 22:58 ` Steven Bosscher 0 siblings, 0 replies; 86+ messages in thread From: Steven Bosscher @ 2004-01-17 22:58 UTC (permalink / raw) To: Steven Bosscher, Diego Novillo, Joseph S. Myers, jh, gp; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-17 11:16 ` Joseph S. Myers 2004-01-17 17:50 ` Diego Novillo @ 2004-01-17 23:38 ` Toon Moene 2004-01-18 1:06 ` Phil Edwards 1 sibling, 1 reply; 86+ messages in thread From: Toon Moene @ 2004-01-17 23:38 UTC (permalink / raw) To: Joseph S. Myers; +Cc: Diego Novillo, Gerald Pfeifer, gcc 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) ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-17 23:38 ` [RFC] Contributing tree-ssa to mainline Toon Moene @ 2004-01-18 1:06 ` Phil Edwards 0 siblings, 0 replies; 86+ messages in thread From: Phil Edwards @ 2004-01-18 1:06 UTC (permalink / raw) To: Toon Moene; +Cc: Joseph S. Myers, Diego Novillo, Gerald Pfeifer, gcc 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 ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-17 0:44 ` Gerald Pfeifer ` (3 preceding siblings ...) 2004-01-17 1:02 ` Joseph S. Myers @ 2004-01-17 2:15 ` Steven Bosscher 2004-01-17 3:01 ` Robert Dewar 4 siblings, 1 reply; 86+ messages in thread From: Steven Bosscher @ 2004-01-17 2:15 UTC (permalink / raw) To: Gerald Pfeifer, Diego Novillo; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-17 2:15 ` Steven Bosscher @ 2004-01-17 3:01 ` Robert Dewar 0 siblings, 0 replies; 86+ messages in thread From: Robert Dewar @ 2004-01-17 3:01 UTC (permalink / raw) To: Steven Bosscher; +Cc: Gerald Pfeifer, Diego Novillo, gcc 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 ... ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-17 0:19 [RFC] Contributing tree-ssa to mainline Diego Novillo ` (2 preceding siblings ...) 2004-01-17 0:44 ` Gerald Pfeifer @ 2004-01-17 11:08 ` Andrew Walrond 2004-01-17 23:33 ` Toon Moene 2004-01-17 14:30 ` Scott Robert Ladd ` (2 subsequent siblings) 6 siblings, 1 reply; 86+ messages in thread From: Andrew Walrond @ 2004-01-17 11:08 UTC (permalink / raw) To: gcc 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 ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-17 11:08 ` Andrew Walrond @ 2004-01-17 23:33 ` Toon Moene 0 siblings, 0 replies; 86+ messages in thread From: Toon Moene @ 2004-01-17 23:33 UTC (permalink / raw) To: Andrew Walrond; +Cc: gcc 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) ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-17 0:19 [RFC] Contributing tree-ssa to mainline Diego Novillo ` (3 preceding siblings ...) 2004-01-17 11:08 ` Andrew Walrond @ 2004-01-17 14:30 ` Scott Robert Ladd 2004-01-17 14:57 ` Paul Brook 2004-01-17 19:01 ` Mark Mitchell 2004-01-17 19:22 ` Daniel Jacobowitz 6 siblings, 1 reply; 86+ messages in thread From: Scott Robert Ladd @ 2004-01-17 14:30 UTC (permalink / raw) To: gcc mailing list 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 ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-17 14:30 ` Scott Robert Ladd @ 2004-01-17 14:57 ` Paul Brook 2004-01-17 15:28 ` Scott Robert Ladd 2004-01-17 21:24 ` law 0 siblings, 2 replies; 86+ messages in thread From: Paul Brook @ 2004-01-17 14:57 UTC (permalink / raw) To: Scott Robert Ladd, gcc mailing list 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 ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-17 14:57 ` Paul Brook @ 2004-01-17 15:28 ` Scott Robert Ladd 2004-01-17 21:24 ` law 1 sibling, 0 replies; 86+ messages in thread From: Scott Robert Ladd @ 2004-01-17 15:28 UTC (permalink / raw) To: Paul Brook; +Cc: gcc mailing list 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 ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-17 14:57 ` Paul Brook 2004-01-17 15:28 ` Scott Robert Ladd @ 2004-01-17 21:24 ` law 2004-01-17 21:47 ` Diego Novillo 1 sibling, 1 reply; 86+ messages in thread From: law @ 2004-01-17 21:24 UTC (permalink / raw) To: Paul Brook; +Cc: Scott Robert Ladd, gcc mailing list 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 ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-17 21:24 ` law @ 2004-01-17 21:47 ` Diego Novillo 0 siblings, 0 replies; 86+ messages in thread From: Diego Novillo @ 2004-01-17 21:47 UTC (permalink / raw) To: Jeff Law; +Cc: Paul Brook, Scott Robert Ladd, gcc mailing list 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. ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-17 0:19 [RFC] Contributing tree-ssa to mainline Diego Novillo ` (4 preceding siblings ...) 2004-01-17 14:30 ` Scott Robert Ladd @ 2004-01-17 19:01 ` Mark Mitchell 2004-01-17 19:23 ` Andrew Pinski 2004-01-20 1:39 ` Kaveh R. Ghazi 2004-01-17 19:22 ` Daniel Jacobowitz 6 siblings, 2 replies; 86+ messages in thread From: Mark Mitchell @ 2004-01-17 19:01 UTC (permalink / raw) To: Diego Novillo; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-17 19:01 ` Mark Mitchell @ 2004-01-17 19:23 ` Andrew Pinski 2004-01-18 0:14 ` Toon Moene 2004-01-20 1:39 ` Kaveh R. Ghazi 1 sibling, 1 reply; 86+ messages in thread From: Andrew Pinski @ 2004-01-17 19:23 UTC (permalink / raw) To: Mark Mitchell; +Cc: gcc, Andrew Pinski, Diego Novillo 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 ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-17 19:23 ` Andrew Pinski @ 2004-01-18 0:14 ` Toon Moene 0 siblings, 0 replies; 86+ messages in thread From: Toon Moene @ 2004-01-18 0:14 UTC (permalink / raw) To: Andrew Pinski; +Cc: Mark Mitchell, gcc, Diego Novillo 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) ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-17 19:01 ` Mark Mitchell 2004-01-17 19:23 ` Andrew Pinski @ 2004-01-20 1:39 ` Kaveh R. Ghazi 2004-01-20 2:00 ` Gabriel Dos Reis ` (2 more replies) 1 sibling, 3 replies; 86+ messages in thread From: Kaveh R. Ghazi @ 2004-01-20 1:39 UTC (permalink / raw) To: mark; +Cc: Joe.Buck, dnovillo, gcc, law > (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 ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-20 1:39 ` Kaveh R. Ghazi @ 2004-01-20 2:00 ` Gabriel Dos Reis 2004-01-20 2:08 ` Mark Mitchell 2004-01-20 15:19 ` Scott Robert Ladd 2004-01-20 2:09 ` Diego Novillo 2004-01-22 8:49 ` Gerald Pfeifer 2 siblings, 2 replies; 86+ messages in thread From: Gabriel Dos Reis @ 2004-01-20 2:00 UTC (permalink / raw) To: Kaveh R. Ghazi; +Cc: mark, Joe.Buck, dnovillo, gcc, law "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 ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-20 2:00 ` Gabriel Dos Reis @ 2004-01-20 2:08 ` Mark Mitchell 2004-01-20 2:31 ` Gabriel Dos Reis 2004-01-20 15:19 ` Scott Robert Ladd 1 sibling, 1 reply; 86+ messages in thread From: Mark Mitchell @ 2004-01-20 2:08 UTC (permalink / raw) To: Gabriel Dos Reis; +Cc: Kaveh R. Ghazi, Joe.Buck, dnovillo, gcc, law > 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 ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-20 2:08 ` Mark Mitchell @ 2004-01-20 2:31 ` Gabriel Dos Reis 0 siblings, 0 replies; 86+ messages in thread From: Gabriel Dos Reis @ 2004-01-20 2:31 UTC (permalink / raw) To: Mark Mitchell; +Cc: Kaveh R. Ghazi, Joe.Buck, dnovillo, gcc, law 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 ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-20 2:00 ` Gabriel Dos Reis 2004-01-20 2:08 ` Mark Mitchell @ 2004-01-20 15:19 ` Scott Robert Ladd 2004-01-20 15:27 ` Andrew Haley 1 sibling, 1 reply; 86+ messages in thread From: Scott Robert Ladd @ 2004-01-20 15:19 UTC (permalink / raw) To: Gabriel Dos Reis; +Cc: Kaveh R. Ghazi, mark, Joe.Buck, dnovillo, gcc, law 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 ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-20 15:19 ` Scott Robert Ladd @ 2004-01-20 15:27 ` Andrew Haley 0 siblings, 0 replies; 86+ messages in thread From: Andrew Haley @ 2004-01-20 15:27 UTC (permalink / raw) To: Scott Robert Ladd; +Cc: gcc 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. ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-20 1:39 ` Kaveh R. Ghazi 2004-01-20 2:00 ` Gabriel Dos Reis @ 2004-01-20 2:09 ` Diego Novillo 2004-01-22 8:49 ` Gerald Pfeifer 2 siblings, 0 replies; 86+ messages in thread From: Diego Novillo @ 2004-01-20 2:09 UTC (permalink / raw) To: Kaveh R. Ghazi; +Cc: Mark Mitchell, Joe.Buck, gcc, Jeff Law 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. ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-20 1:39 ` Kaveh R. Ghazi 2004-01-20 2:00 ` Gabriel Dos Reis 2004-01-20 2:09 ` Diego Novillo @ 2004-01-22 8:49 ` Gerald Pfeifer 2 siblings, 0 replies; 86+ messages in thread From: Gerald Pfeifer @ 2004-01-22 8:49 UTC (permalink / raw) To: Kaveh R. Ghazi; +Cc: Mark Mitchell, Joe.Buck, Diego Novillo, gcc, Jeffrey A Law 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/ ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-17 0:19 [RFC] Contributing tree-ssa to mainline Diego Novillo ` (5 preceding siblings ...) 2004-01-17 19:01 ` Mark Mitchell @ 2004-01-17 19:22 ` Daniel Jacobowitz 2004-01-17 19:34 ` Richard Guenther 6 siblings, 1 reply; 86+ messages in thread From: Daniel Jacobowitz @ 2004-01-17 19:22 UTC (permalink / raw) To: gcc 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 ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-17 19:22 ` Daniel Jacobowitz @ 2004-01-17 19:34 ` Richard Guenther 2004-01-17 20:21 ` Steven Bosscher 2004-01-18 1:24 ` David Edelsohn 0 siblings, 2 replies; 86+ messages in thread From: Richard Guenther @ 2004-01-17 19:34 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: gcc 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. ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-17 19:34 ` Richard Guenther @ 2004-01-17 20:21 ` Steven Bosscher 2004-01-18 1:24 ` David Edelsohn 1 sibling, 0 replies; 86+ messages in thread From: Steven Bosscher @ 2004-01-17 20:21 UTC (permalink / raw) To: Richard Guenther, Daniel Jacobowitz; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [RFC] Contributing tree-ssa to mainline 2004-01-17 19:34 ` Richard Guenther 2004-01-17 20:21 ` Steven Bosscher @ 2004-01-18 1:24 ` David Edelsohn 1 sibling, 0 replies; 86+ messages in thread From: David Edelsohn @ 2004-01-18 1:24 UTC (permalink / raw) To: Richard Guenther; +Cc: Daniel Jacobowitz, gcc >>>>> 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 ^ permalink raw reply [flat|nested] 86+ messages in thread
end of thread, other threads:[~2004-01-29 0:00 UTC | newest] Thread overview: 86+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2004-01-17 0:19 [RFC] Contributing tree-ssa to mainline Diego Novillo 2004-01-17 0:31 ` Daniel Berlin 2004-01-17 0:35 ` Andrew Pinski 2004-01-17 0:44 ` Gerald Pfeifer 2004-01-17 0:53 ` law 2004-01-17 0:54 ` law 2004-01-17 1:37 ` Gerald Pfeifer 2004-01-17 1:46 ` Diego Novillo 2004-01-17 0:55 ` Eric Christopher 2004-01-17 2:48 ` Robert Dewar 2004-01-17 22:08 ` Eric Christopher 2004-01-17 1:02 ` Joseph S. Myers 2004-01-17 1:51 ` Kaveh R. Ghazi 2004-01-17 2:01 ` Gabriel Dos Reis 2004-01-17 2:17 ` Kaveh R. Ghazi 2004-01-17 3:01 ` Daniel Berlin 2004-01-17 2:19 ` Steven Bosscher 2004-01-17 3:02 ` Robert Dewar 2004-01-17 3:55 ` Andrew Pinski 2004-01-17 3:36 ` Diego Novillo 2004-01-17 13:06 ` Giovanni Bajo 2004-01-17 13:53 ` Jan Hubicka 2004-01-18 7:01 ` law 2004-01-17 17:04 ` Kaveh R. Ghazi 2004-01-17 17:16 ` Scott Robert Ladd 2004-01-17 17:30 ` Kaveh R. Ghazi 2004-01-17 17:50 ` Scott Robert Ladd 2004-01-17 17:37 ` Robert Dewar 2004-01-17 17:46 ` Joseph S. Myers 2004-01-17 17:51 ` Robert Dewar 2004-01-17 18:11 ` Joseph S. Myers 2004-01-17 19:12 ` Arnaud Charlet 2004-01-19 12:19 ` Ada commits to branch (was: [RFC] Contributing tree-ssa to mainline) Laurent GUERBY 2004-01-19 12:23 ` Arnaud Charlet 2004-01-19 18:35 ` Laurent GUERBY 2004-01-19 22:11 ` Arnaud Charlet 2004-01-19 22:22 ` Laurent GUERBY 2004-01-29 0:36 ` [RFC] Contributing tree-ssa to mainline Robert Dewar 2004-01-29 0:00 ` Robert Dewar 2004-01-17 17:58 ` Scott Robert Ladd 2004-01-17 18:09 ` Joseph S. Myers 2004-01-17 18:06 ` Mark Mitchell 2004-01-18 7:15 ` law 2004-01-18 15:50 ` Daniel Berlin 2004-01-17 17:12 ` Kaveh R. Ghazi 2004-01-17 17:26 ` Diego Novillo 2004-01-17 5:31 ` Diego Novillo 2004-01-17 6:15 ` law 2004-01-17 6:22 ` Andrew Pinski 2004-01-17 6:38 ` Diego Novillo 2004-01-17 14:45 ` Daniel Berlin 2004-01-17 21:23 ` law 2004-01-17 21:33 ` Steven Bosscher 2004-01-18 2:34 ` Zack Weinberg 2004-01-17 11:16 ` Joseph S. Myers 2004-01-17 17:50 ` Diego Novillo 2004-01-17 18:06 ` Joseph S. Myers 2004-01-17 20:14 ` Steven Bosscher 2004-01-17 22:55 ` cfg.texi (was: [RFC] Contributing tree-ssa to mainline) Steven Bosscher 2004-01-17 22:58 ` Steven Bosscher 2004-01-17 23:38 ` [RFC] Contributing tree-ssa to mainline Toon Moene 2004-01-18 1:06 ` Phil Edwards 2004-01-17 2:15 ` Steven Bosscher 2004-01-17 3:01 ` Robert Dewar 2004-01-17 11:08 ` Andrew Walrond 2004-01-17 23:33 ` Toon Moene 2004-01-17 14:30 ` Scott Robert Ladd 2004-01-17 14:57 ` Paul Brook 2004-01-17 15:28 ` Scott Robert Ladd 2004-01-17 21:24 ` law 2004-01-17 21:47 ` Diego Novillo 2004-01-17 19:01 ` Mark Mitchell 2004-01-17 19:23 ` Andrew Pinski 2004-01-18 0:14 ` Toon Moene 2004-01-20 1:39 ` Kaveh R. Ghazi 2004-01-20 2:00 ` Gabriel Dos Reis 2004-01-20 2:08 ` Mark Mitchell 2004-01-20 2:31 ` Gabriel Dos Reis 2004-01-20 15:19 ` Scott Robert Ladd 2004-01-20 15:27 ` Andrew Haley 2004-01-20 2:09 ` Diego Novillo 2004-01-22 8:49 ` Gerald Pfeifer 2004-01-17 19:22 ` Daniel Jacobowitz 2004-01-17 19:34 ` Richard Guenther 2004-01-17 20:21 ` Steven Bosscher 2004-01-18 1:24 ` David Edelsohn
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).