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

[Richard Guenther <rguenth at tat dot physik dot uni-tuebingen dot de>]

On Fri, 21 Jan 2005, Zdenek Dvorak wrote:

> Hello,
>
> > So I really wonder, if SRA inside loop is ever going to work as
> > good as an extra early loop pass completely unrolling loops.
> > As a conclusion I would stick with the extra early loop pass for
> > 4.0 - everything else is way too invasive now.
> >
> > Any other ideas?
>
> I think we should just let things as they are for 4.0 and concentrate on
> getting it right in 4.1.  Early cunroll pass enabled by a separate flag

Ah - don't we say this ever for gcc version +1 ? ;)

> 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 -- do you
really want to throw all the load of optimizers at completely
unrolled loops _again_?

Richard.

--
Richard Guenther <richard dot guenther at uni-tuebingen dot de>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/