Loop optimizer issues

[Jan Hubicka]

> In message <87oezd40qr.fsf@egil.codesourcery.com>, "Zack Weinberg" writes:
>  >Jason Merrill <jason@redhat.com> writes:
>  >
>  >> I think there's been a bit of a disconnect in this discussion.
>  >>
>  >> Some people are arguing against merging the rtlopt changes into tree-ssa.
>  >> Some people are arguing for merging Zdenek's loop optimizer work into
>  >> tree-ssa.
>  >>
>  >> Nobody, AFAICT, is arguing for merging all of rtlopt into tree-ssa.
>  >
>  >Actually, I *am* arguing for merging all of rtlopt into *somewhere*,
>  >because the code on the rtlopt branch dies when tree-ssa hits
>  >mainline, so either it gets merged somewhere now or we lose all that
>  >work.
> I simply can't support merging all of rtlopt into the SSA branch.  It
> makes a ton of work for us with little benefit to the SSA project.
> 
> I would consider merging generic code which does analysis and transformations
> on the CFG, but merging all of rtlopt just doesn't make sense for the SSA
> branch.
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)
My plan has been to continue in the scheme we did so far - create new
3.4 based branch (rtlopt-3-4-branch?), do the merge together with review
of the code and start commiting incremental patches once mainline opens
for branch merging again probably with the exception of Zdenek's loop
optimizer work that is big enought to deserve special attention.

But I am open to the alternatives as this process is definitly somewhat
demanding and apparently the amount of changes falling off is increasing
so this method is not going to work with 100% sucess in pushing the code
in mainline in the long term.  On the other hand not all the code is
perfect and I believe always the better/more polished parts gets in
first.

Honza
> 
> Sorry,
> jeff
> 
>