[PATCH] Fix PR18754: add early loop pass, 2nd try

[Richard Guenther]

Daniel Berlin wrote:
> On Fri, 2005-01-21 at 17:15 +0100, Richard Guenther wrote:
> 
>>On Fri, 21 Jan 2005, Zdenek Dvorak wrote:
> 
> 
>>	NEXT_PASS (pass_complete_unroll); (with loop cfg_cleanup)
>>	NEXT_PASS (pass_ccp);
>>        NEXT_PASS (pass_sra);  -- results look ok
>>        NEXT_PASS (pass_ccp);
>>        NEXT_PASS (pass_dce);
>>        NEXT_PASS (pass_fre);
>>        NEXT_PASS (pass_iv_optimize);
>>
>>and still before iv_optimize we have multiple-BB inner loop and
>>ivopts is breaking down.  Obviously we need another round of
>>jump threading and bb-merging/moving to get there -- do you
>>really want to throw all the load of optimizers at completely
>>unrolled loops _again_?
> 
> 
> Our optimizers are supposed to be fast.
> I have plans to lower address arithmetic, and then throw lowered address
> arithmetic at at least 4 of them after loop is completely done.
> Not that we should randomly be adding pass calls where we could just fix
> optimizers, but, if they need to be run, they need to be run.

Isn't this true for an early cunroll pass, too?  Remember that people 
are working around the lack of this since ages by abusing the inliner
(can you say template metaprogramming?).  I just want to ask you, what
is the value of keeping these loops until the current time?  Even the 
vectorizer is hindered by these loops, as it bails out for all but the
innermost loops, which these to be completely unrolled loops are (of 
course - fix the vectorizer, run it again after cunroll, or just move it 
after cunroll, etc).

Richard.