This is the mail archive of the gcc-patches@gcc.gnu.org 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


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.


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