This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Fix PR18754: add early loop pass, 2nd try
- From: Richard Guenther <rguenth at tat dot physik dot uni-tuebingen dot de>
- To: Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>
- Cc: Daniel Berlin <dberlin at dberlin dot org>,Giovanni Bajo <giovannibajo at libero dot it>, <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 21 Jan 2005 17:15:37 +0100 (CET)
- Subject: Re: [PATCH] Fix PR18754: add early loop pass, 2nd try
On Fri, 21 Jan 2005, Zdenek Dvorak wrote:
> > 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
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_sra); -- results look ok
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 Guenther <richard dot guenther at uni-tuebingen dot de>