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

[Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>]

Hello,

> > is definitely a bad idea.  Early cunroll pass enabled unconditionally
> > is a hack -- if the code is too messy after cunroll, the right fix is to
> > put there cleanup pass(es) anyway, for the benefit of other loop
> > optimizations.
> 
> I see early cunroll pass as a cheap way to get the maximum benefit
> out of optimization passes that run anyway.  I also think that these
> loops that are completely unrolled by the compiler are artificial
> and should be removed as early as possible to not hinder other
> passes at doing their optimization.
> 
> I am now at
> 
> 	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

All of this should happen in cfg cleanup; if this happens to you,
there is probably some bug somewhere.  Could you please send
me your patch + testcase, I will have a look at that?

> -- do you
> really want to throw all the load of optimizers at completely
> unrolled loops _again_?

yes.  I believe that it still might be cheaper than doing cunroll
early and letting *all* optimization passes to work with larger
code.  All of ccp, dce and fre are fast passes that are expected
to be run several times.

Zdenek