This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


> > 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]