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.