Re: [patch] Enable fmove-loop-invariants by default

[Roger Sayle <roger at eyesopen dot com>]

On Fri, 10 Feb 2006, Zdenek Dvorak wrote:
>
> 	* doc/invoke.texi (-floop-optimize2): Removed.
> 	* toplev.c (process_options): Remove handling of flag_loop_optimize2.
> 	* loop-init.c (gate_handle_loop2): Do not test flag_loop_optimize2.
> 	Test flag_branch_on_count_reg only if HAVE_doloop_end.
> 	* common.opt (floop-optimize2): Removed.
> 	(fmove-loop-invariants): Enabled by default.
>
> 	* gcc.dg/20050105-1.c: Do not use -floop-optimize2.

This is OK for mainline.  Normally, I'd prefer these two changes
to be kept separate, as there's a relatively high probability that
we may need to disable fmove-loop-invariants again if anything bad
happens, and mixing clean-ups with functional changes complicates
reverting things.  Fortunately, in this case its a one-line change
to return to the old behaviour.


Please let me know of any performance impact of this change.

Whilst I'm strongly in favor of getting rid of loop.c, the decision
is ultimately dependent upon how well the tree-ssa loop optimizations
replace its functionality.  The only reason loop.c wasn't removed
in 4.0 or 4.1, is because it would hurt code performance too much.
Do we have the current numbers for where we are?

Before StevenB complains, one motivation is that we could decide
to kill loop.c early, with perhaps a 5% performance loss, whilst
still in stage1, which would provide motivation/opportunity to fix
the remainaing issues as "regressions" during stage2 and stage3.
Alternatively, if we're not ready yet, its good to know that too.

It would also help prioritizing the remaining killloop patches if
we knew the relative benefits of each.  Getting the "big wins" in
early would be preferable.

Roger
--