LNO Branch merge proposal

LNO Branch merge proposal

[David Edelsohn]

	The developers of the LNO Branch, with support from Apple
Computer, Inc., IBM Corporation, and SUSE, plan to contribute the branch
for merger into mainline shortly after Tree-SSA is merged into mainline.
We suggest one to three weeks after Tree-SSA is merged to allow for settling
of that merge.

	As with Tree-SSA, the new functions and options will be well
documented and we request code reviews and feedback for all components of
the branch.

	The proposed testing requirement is that LNO branch will show no
testsuite regressions with respect to mainline (after the Tree-SSA merge)
for the same targets specified for the Tree-SSA merge.

	The new features are considered a technology preview.  We do not
propose enabling the new functionality at any default -O optimization
level in GCC until a more thorough cost-benefit analysis has been
performed.  This is an implicit commitment that merging LNO will not
affect compilation speed when LNO options remain disabled.

	Testing of the branch shows performance improvements and many
developers are eager to have LNO available to begin to show the full
performance potential of Tree-SSA.  However, for the next GCC release,
correctness will be the focus of the code on mainline.  We will address
any ICEs and wrong-code reported by users invoking LNO optimizations.

Re: LNO Branch merge proposal

[law]

In message <200403171923.i2HJN9T35164@makai.watson.ibm.com>, David Edelsohn wri
tes:
 >	The developers of the LNO Branch, with support from Apple
 >Computer, Inc., IBM Corporation, and SUSE, plan to contribute the branch
 >for merger into mainline shortly after Tree-SSA is merged into mainline.
 >We suggest one to three weeks after Tree-SSA is merged to allow for settling
 >of that merge.
I think it's way too soon to consider doing this.   I don't even think 
anyone with global write privs is even working with that code right now.

Contrast that to the tree-ssa branch where Richard, Jason, and myself are
all actively developing code.

jeff

Re: LNO Branch merge proposal

[Scott Robert Ladd]

David Edelsohn wrote:
> 	Testing of the branch shows performance improvements and many
> developers are eager to have LNO available to begin to show the full
> performance potential of Tree-SSA.  However, for the next GCC release,
> correctness will be the focus of the code on mainline.  We will address
> any ICEs and wrong-code reported by users invoking LNO optimizations.

I, for one, am very eager to see this branch merged.

..Scott

Re: LNO Branch merge proposal

[Daniel Berlin]

On Wed, 17 Mar 2004 law@redhat.com wrote:

> In message <200403171923.i2HJN9T35164@makai.watson.ibm.com>, David Edelsohn wri
> tes:
> I think it's way too soon to consider doing this.

why?
  I don't even think
> anyone with global write privs is even working with that code right now.
>

Um, so?

I don't see how that has any relevance to anyhing?
maybe you could expand a bit?

> Contrast that to the tree-ssa branch where Richard, Jason, and myself are
> all actively developing code.
>
> jeff
>
>

Re: LNO Branch merge proposal

[David Edelsohn]

>>>>> Jef Law writes:

Jeff> In message <200403171923.i2HJN9T35164@makai.watson.ibm.com>, David Edelsohn wri
Jeff> tes:
>> The developers of the LNO Branch, with support from Apple
>> Computer, Inc., IBM Corporation, and SUSE, plan to contribute the branch
>> for merger into mainline shortly after Tree-SSA is merged into mainline.
>> We suggest one to three weeks after Tree-SSA is merged to allow for settling
>> of that merge.

Jeff> I think it's way too soon to consider doing this.   I don't even think 
Jeff> anyone with global write privs is even working with that code right now.

Jeff> Contrast that to the tree-ssa branch where Richard, Jason, and myself are
Jeff> all actively developing code.

	If any developers with GWP want to work more actively in the LNO
branch, we would welcome it.  Richard has toyed with the
auto-vectorization and provided valuable feedback.

	LNO fundamentally is a different type of change than Tree-SSA
itself.  Tree-SSA is a conversion of the GCC infrastructure and cannot be
disabled once merged.  LNO is infrastructure built on top of Tree-SSA that
can be enabled and disabled.

	There have been many large patches developed without GWP
involvement, so I do not understand why this patch is any different.  We
specifically have developed the functionality in the branch to make it
easy for everyone to observe the development and experiment with the
branch.

	We see no benefit to delaying integration.  It will not hurt
performance or compile time.  The features have a long term commitment
from developers and their sponsors.  It allows early access to the
features.  It greatly simplifies LNO development avoiding complicated
merges by having the infrastructure maintained implicitly with mainline.

David

Re: LNO Branch merge proposal

[law]

In message <4058AD17.6090007@coyotegulch.com>, Scott Robert Ladd writes:
 >David Edelsohn wrote:
 >> 	Testing of the branch shows performance improvements and many
 >> developers are eager to have LNO available to begin to show the full
 >> performance potential of Tree-SSA.  However, for the next GCC release,
 >> correctness will be the focus of the code on mainline.  We will address
 >> any ICEs and wrong-code reported by users invoking LNO optimizations.
 >
 >I, for one, am very eager to see this branch merged.
So am I, but, for example, we don't have any of the long time GCC
developers doing design/implementation reviews on that branch right now.

That's a very different situation than what you would find on the
tree-ssa branch where Richard, Jason and myself work with Diego,
Andrew, Jan, Zdenek on design and implementation issues.

I'm not saying that we shouldn't be looking to merge LNO, I'm saying I
think David's schedule is far too aggressive.

jeff

Re: LNO Branch merge proposal

[Diego Novillo]

Merging LNO is an excellent idea.  However, I'm not sure what to think
about the timing of the proposal.  I *very* *much* want LNO to be part
of GCC.  It is clear that to compete with the likes of ICC and Open64 we
need this technology.  That's precisely why I don't want us rushing into
incorporating it too early.

While it would be very cool to have LNO integrated, the fact that none
of the optimizers are triggered by default may be a bit of a problem. 
This was the situation we had in Tree SSA more than a year ago.

Not having the optimizers trigger by default means that there are a
significant number of bugs that we still haven't discovered.  Bugs that
may force us to reconsider design decisions.  Bugs that we may not be
able to fix for a long time because of our release schedule and which
have the potential of saturating Bugzilla.

We have had a history of technology preview flags that ended up
abandoned or are limping along, not quite finished.  From my personal
experience, branches are wonderful for this type of situation.  We have
new cool stuff that we can break at will and reshape without paying
attention to what goes on in mainline.

Little by little we make the different switches trigger by default, fix
bugs and then dump the whole thing into mainline.  Merging LNO with all
the switches disabled, means that the bugs may not get discovered for a
long time, because the passes won't trigger by default.

While Tree SSA stabilizes, we will have all the global maintainers
poring over it and probably making changes that may have an impact on
LNO.  Do we want to overload ourselves with the combined tree-ssa and
lno merge?

The other questions are the same we asked of tree-ssa: what about
compile and run time performance?  memory consumption?  We already have
a problem with that in tree-ssa.  How much worse/better is it on LNO? 
How does SPEC look like?  Are we beating mainline?  Are we close to ICC?

Interesting times indeed.


Diego.

Re: LNO Branch merge proposal

[Richard Henderson]

On Wed, Mar 17, 2004 at 02:23:09PM -0500, David Edelsohn wrote:
> 	The developers of the LNO Branch, with support from Apple
> Computer, Inc., IBM Corporation, and SUSE, plan to contribute the branch
> for merger into mainline shortly after Tree-SSA is merged into mainline.
> We suggest one to three weeks after Tree-SSA is merged to allow for settling
> of that merge.

I would suggest *not* merging the entire LNO branch en masse, but
rather extracting the various parts and having them reviewed as 
with any regular development.

As you yourself said, there's nothing revolutionary about LNO,
its merely a set of passes on top of tree-ssa.  As such, I see
no compelling reason for it to be merged as a whole.

I would suggest that the merge process begin with the new LNO
infrastructure bits (ivs, dependency analysis, etc), and then
proceed with the higher-level transforms.



r~

Re: LNO Branch merge proposal

[David Edelsohn]

>>>>> Diego Novillo writes:

Diego> While it would be very cool to have LNO integrated, the fact that none
Diego> of the optimizers are triggered by default may be a bit of a problem. 

	High-level loop optimizations and auto-vectorization are not
enabled by default in most compilers.  We are trying to improve GCC
performance on benchmarks, but we are not trying to transform GCC into a
benchmark compiler when invoked under normal operating conditions.

Diego> We have had a history of technology preview flags that ended up
Diego> abandoned or are limping along, not quite finished.  From my personal
Diego> experience, branches are wonderful for this type of situation.  We have
Diego> new cool stuff that we can break at will and reshape without paying
Diego> attention to what goes on in mainline.

	What technology previews in GCC with long-term commitments of
support for developers have been abandoned?

Diego> The other questions are the same we asked of tree-ssa: what about
Diego> compile and run time performance?  memory consumption?  We already have
Diego> a problem with that in tree-ssa.  How much worse/better is it on LNO? 
Diego> How does SPEC look like?  Are we beating mainline?  Are we close to ICC?

	GCC performance with LNO is closeR to ICC, but no new features are
going to get GCC close to ICC from day one.

	LNO will not be enabled by default, so it cannot have any impact
on compile time, run time, or memory consumption.  Only diskspace.  High
level loop transformations are complicated and expensive.  One enables
them selectively at very high optimization for applications that will
benefit from those transformations and are willing to pay the compile time
price. 

	Merging LNO into mainline is very low risk and will not impact the
release schedule.  And merging it in will accelerate the development of
GCC itself and of LNO features.  Is there some reason to discourage rapid
improvement in GCC performance?

	Many GCC developers have been looking for increased contribution
of technology to GCC.  It would be a shame to discourage those efforts and
pass up an opportunity.

David

Re: LNO Branch merge proposal

[Richard Guenther]

Richard Henderson wrote:
> On Wed, Mar 17, 2004 at 02:23:09PM -0500, David Edelsohn wrote:
> 
>>	The developers of the LNO Branch, with support from Apple
>>Computer, Inc., IBM Corporation, and SUSE, plan to contribute the branch
>>for merger into mainline shortly after Tree-SSA is merged into mainline.
>>We suggest one to three weeks after Tree-SSA is merged to allow for settling
>>of that merge.
> 
> I would suggest *not* merging the entire LNO branch en masse, but
> rather extracting the various parts and having them reviewed as 
> with any regular development.
> 
> As you yourself said, there's nothing revolutionary about LNO,
> its merely a set of passes on top of tree-ssa.  As such, I see
> no compelling reason for it to be merged as a whole.
> 
> I would suggest that the merge process begin with the new LNO
> infrastructure bits (ivs, dependency analysis, etc), and then
> proceed with the higher-level transforms.

I specifically would like to have the basic loop optimizations such as 
IV optimization and unrolling merged.  Vectorization and LNO can wait, 
IMHO.  So eventually we could get rid of (parts of) the rtl level loop 
optimizers.

Richard.

Re: LNO Branch merge proposal

[Diego Novillo]

On Wed, 2004-03-17 at 16:32, David Edelsohn wrote:

> 	High-level loop optimizations and auto-vectorization are not
> enabled by default in most compilers.  We are trying to improve GCC
> performance on benchmarks, but we are not trying to transform GCC into a
> benchmark compiler when invoked under normal operating conditions.
> 
The basic loop stuff we do at -O2 should trigger by default.  That will
exercise the basic framework.

> 	What technology previews in GCC with long-term commitments of
> support for developers have been abandoned?
> 
-fssa has been abandoned.  -fnew-ra is limping along.

> 	Many GCC developers have been looking for increased contribution
> of technology to GCC.  It would be a shame to discourage those efforts and
> pass up an opportunity.
> 
Don't be so melodramatic.  Tree SSA thrived inside a branch and nobody
felt discouraged because of it.  On the contrary.

I am not opposed to merging LNO.  Get that straight.  I just want to
make sure we don't trip over in our haste to bring everything together. 
Doing it in stages like Richard suggested seems to me like a good idea.


Diego.

Re: LNO Branch merge proposal

[David Edelsohn]

>>>>> Richard Henderson writes:

Richard> I would suggest *not* merging the entire LNO branch en masse, but
Richard> rather extracting the various parts and having them reviewed as 
Richard> with any regular development.

Richard> As you yourself said, there's nothing revolutionary about LNO,
Richard> its merely a set of passes on top of tree-ssa.  As such, I see
Richard> no compelling reason for it to be merged as a whole.

Richard> I would suggest that the merge process begin with the new LNO
Richard> infrastructure bits (ivs, dependency analysis, etc), and then
Richard> proceed with the higher-level transforms.

	As long as we do not arbitrarily cut off patches for GCC 3.5
before all LNO work has been reviewed and merged, there probably is little
difference.  LNO presumably would be reviewed in pieces anyway.

	A purpose of proposing the LNO branch is to alert everyone to the
goal and to design a plan to successfully merge the functionality for GCC
3.5.

David

Re: LNO Branch merge proposal

[David Edelsohn]

>>>>> Diego Novillo writes:

>> What technology previews in GCC with long-term commitments of
>> support for developers have been abandoned?

Diego> -fssa has been abandoned.  -fnew-ra is limping along.

	Those options had public, long-term commitments of support from
corporations?

Diego> I am not opposed to merging LNO.  Get that straight.  I just want to
Diego> make sure we don't trip over in our haste to bring everything together. 
Diego> Doing it in stages like Richard suggested seems to me like a good idea.

	Great.

Thanks, David

Re: LNO Branch merge proposal

[Eric Christopher]

> 	As long as we do not arbitrarily cut off patches for GCC 3.5
> before all LNO work has been reviewed and merged, there probably is little
> difference.  LNO presumably would be reviewed in pieces anyway.

"Reviewed and merged if accepted". It's a fine point, but putting a
requirement on 3.5 that depends on code that hasn't had any major review
is perhaps a bit unwise.

-eric

-- 
Eric Christopher <echristo@redhat.com>

Re: LNO Branch merge proposal

[Joseph S. Myers]

On Wed, 17 Mar 2004, David Edelsohn wrote:

> 	LNO will not be enabled by default, so it cannot have any impact
> on compile time, run time, or memory consumption.  Only diskspace.  High

Increased code size can affect compile-time performance, if nothing else
because we don't sort functions in the executable to optimise cache
performance.  Look at the increasing size of cc1, which could well
contribute to slow performance degradation (on i686-pc-linux-gnu):

   text    data     bss     dec     hex version
1026014   16996   68808 1111818  10f70a 2.7.2.3
1286049   19668   73884 1379601  150d11 2.8.1
1296058   19632   69772 1385462  1523f6 egcs-1.0.3a
1438977   18188   78328 1535493  176e05 egcs-1.1.2
1653481   16856   86820 1757157  1acfe5 2.95.3
2439922   15036  434136 2889094  2c1586 3.0.4
2889499    6192  692608 3588299  36c0cb 3.2.3
3083133    2624  746656 3832413  3a7a5d 3.3.3
3464870    3192  529120 3997182  3cfdfe 3.4 branch
(mainline omitted since I don't have a --disable-checking mainline 
compiler to hand to compare)

That said, I'd rather see features that require special flags to enable
them present on mainline rather than on a branch with all the merging that
implies.  I've wondered why new-regalloc development sits on a branch
(with bug reports from people testing -fnew-ra other than on that branch
being fairly useless) when -fnew-ra is needed to enable the new allocator.

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

Re: LNO Branch merge proposal

[Jan Hubicka]

> In message <200403171923.i2HJN9T35164@makai.watson.ibm.com>, David Edelsohn wri
> tes:
>  >	The developers of the LNO Branch, with support from Apple
>  >Computer, Inc., IBM Corporation, and SUSE, plan to contribute the branch
>  >for merger into mainline shortly after Tree-SSA is merged into mainline.
>  >We suggest one to three weeks after Tree-SSA is merged to allow for settling
>  >of that merge.
> I think it's way too soon to consider doing this.   I don't even think 
> anyone with global write privs is even working with that code right now.
> 
> Contrast that to the tree-ssa branch where Richard, Jason, and myself are
> all actively developing code.

Some guideline on how branch merging in post-ssa world will be organized
would be usefull tought.  The tree-profiling branch now have CFG
transparent optimizations all from tree build_cfg to final with the
single expection of old loop optimizer (currently disabled now).
It also has working coverage support and profile available to tree
optimizers.

After fixing funny bug causing every conditional to be output twice it
_seems_ to be 5% faster than tree-ssa (I find it very hard to believe
but it is what tester claims), code seems to be 1% slower for reason I
don't understand (it is not disabled loop) too, so I need to look into
it deeper before claiming something.

We still have some way to go before getting profile based inlining but
it would be nice to have some roadmap synchronized with mainline.

Honza

Re: LNO Branch merge proposal

[Zdenek Dvorak]

Hello,

> Merging LNO is an excellent idea.  However, I'm not sure what to think
> about the timing of the proposal.  I *very* *much* want LNO to be part
> of GCC.  It is clear that to compete with the likes of ICC and Open64 we
> need this technology.  That's precisely why I don't want us rushing into
> incorporating it too early.
> 
> While it would be very cool to have LNO integrated, the fact that none
> of the optimizers are triggered by default may be a bit of a problem. 
> This was the situation we had in Tree SSA more than a year ago.
> 
> Not having the optimizers trigger by default means that there are a
> significant number of bugs that we still haven't discovered.  Bugs that
> may force us to reconsider design decisions.  Bugs that we may not be
> able to fix for a long time because of our release schedule and which
> have the potential of saturating Bugzilla.

just a note on the status of the branch (more precisely, the parts that
concern me, i.e. the lower level stuff -- everything that is enabled by
--ftree-loop-optimize -floop-optimize2):

-- basically everything from the old loop optimizer is also implemented
   in the new one (except for prefetching & some minor details)
-- I do regular bootstraps & regtesting on i686
-- the last time I have checked (about 14 days ago) it also bootstrapped
   on ia64 and ppc64
-- it compiles specint, with the following results:

   164.gzip          1400   199       703    *     1400   194       720
   175.vpr           1400   391       358    *     1400   387       362
   176.gcc           1100        --          X     1100        --
   181.mcf           1800   750       240    *     1800   738       244
   186.crafty        1000   117       857    *     1000   117       856
   197.parser        1800   399       451    *     1800   402       447
   252.eon           1300        --          X     1300        --
   253.perlbmk       1800   210       859    *     1800     0.073
   254.gap           1100   179       613    *     1100   182       603
   255.vortex        1900   231       822    *     1900   247       770
   256.bzip2         1500   334       449    *     1500   341       440
   300.twolf         3000   790       380    *     3000   790       380

   The vortex regression seems to be just "bad luck" -- some instruction
   cache problem or something like that (both oprofile and gprof localize
   the regression to the function that contains no loops at all).

I am now planning to do the performance and regression testing on other
architectures than i686 (that due to lack of registers is not really a
great place where to test things like strength reduction).

I have no great preferences about the way these things will be merged,
although I would definitely like to see them in 3.5.  It would be nice
to have it enabled by default (in the same way it is done with the
unroller, i.e. leaving the old loop optimizer alive for some time until
we can guarantee that we do not lose any significant functionality by
removing it), but I understand this might be too adventurous.

Zdenek