This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Loop optimizer issues


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.

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
update the branch from the mainline and then send incremental patches
for review.  Please do test extensively.

zw


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]