Loop optimizer issues

[Jan Hubicka]

> Jan Hubicka <jh@suse.cz> writes:
> 
> > Being familiar with the shape of code, I would agree.  The rtlopt branch
> > was not developed with such a flat merge in a mind.  We were always
> > targetting to merge in incremental steps so all the code gets better
> > review than jump 5MB patch.
> > This scheme works pretty well. I believe the resulting code quality off
> > the cfg-branch and rtlopt mergers were pretty good because of some extra
> > testing it did get on the public branch and the good reviews made by
> > Richard.  Only if there wasn't always some fallout off the merge.  At
> > the moment RTLopt branch contains (not in particular order):
> >  - Zdenek's loop optimizer changes.  I would personally support merging
> >    these with tree-SSA infrastructure and developing both GIMPLE/SSA and RTL
> >    based optimizers.  Merge of SSA branch will likely make our current
> >    loop optimizer no-op by killing loop notes once forever and having
> >    GCC release with no good replacement for it is IMO very bad.
> >  - Zdenek's value range profiling code.  This one is half way in the
> >    mainline.  I really hoped to see this merged in 3.4 but I am not
> >    quite sure this will happen.
> >    This is major problem in merging mainline as Nathanel's work on gcov
> >    did cause gread amount of conflicts..
> >  - my webizer pass (comming from 3.2 times IMO ready for merge but there
> >    are issues with SSA-RTL making it perhaps redundant one day in
> >    future).  Has measurable improvements in perfomrance especially in
> >    combination with Zdenek's new loop unroller that lack induction
> >    variable splitting
> >  - Josef's variable tracking and Daniel's location lists.  I believe
> >    there is useable version sent for review for some time but it has
> >    problem with losing track when value is copied to temporary location
> >    that is later killed.  This is relatively minnor problem in the
> >    algorithm as the interfaces are major problem right now here.
> >
> >    I believe we have to solve this in order to get nice debugging out of
> >    de-SSA once we drop limitations on de-SSAizing.  It is also solving
> >    problems with -frename-registers as well as with webizer rendering
> >    variable values random in debugger.
> >  - Zdenek's cleanup of GCSE.  Improved store motion has been merged but
> >    his breakup of GCSE into multiple files didn't.  I guess in it's
> >    current shape it would need to be redone.
> >  - My code for GCSE on parallels that is actually in cfg branch only and
> >    first halve of the changes went into mainline (basic code motion
> >    infrastructure)
> 
> Thanks for the clarification.  This does change my thinking about it.
> I'd been under the impression that the code on the branch needed to be
> merged more or less all at once.
We were trying hard to avoid this situation during the project as big
merges are always dificult.  Main goal has been to make GCC bit more
ready for adding new optimizers where large portion can be done by
solving individual problems separately.
> 
> Since it can be broken down into chunks, IMHO it is *not* necessary to
> wait for the 3.5 cycle to begin merging the branch into the mainline,
> beginning with the most obvious pieces.  I would encourage you to

I would also hope that we can continue during the stage 2. Everything
where I expected possible surprises is already merged in.
> update the branch from the mainline and then send incremental patches
> for review.  Please do test extensively.

We still do have patches in the queue ready for merging.
Before 3.4 opened I tested all the code on several plaforms to meet the
criterias and also majority of changes were backported into hammer
branch and tested in the distribution build environment.

It would be cool to integrate the Zdenek's value range profiling code
first so I can simply drop the code in conflict with Nathanel's
reorganization.  That would make merging possible (I tried to merge it
twice already but always just gave up because of too many conflicts in
these files)
The Zdenek's patch is at
http://gcc.gnu.org/ml/gcc-patches/2003-06/msg02953.html

Honza
> 
> zw