On Wed, Aug 19, 2009 at 3:56 PM, Richard Guenther<richard.guent...@gmail.com> wrote: > On Wed, Aug 19, 2009 at 3:54 PM, Albert Cohen<albert.co...@inria.fr> wrote: >> Albert Cohen wrote: >>> Thanks a lot for the quick and detailed response. >>> >>> It is more difficult than I thought, then :-( We'll think more, and >>> maybe come up with yet another pass ordering proposal, but definitely >>> this tramp3d code deserves to be processed by graphite AFTER >>> unrolling+cse has done its specialization trick. >> >> One way out would be to make unrolli pass a little more careful. As you >> suggest, the heuristic is already not quite satisfactory as it sometimes >> unrolls outemost loops. >> >> A better heursitic would be to run through the different cases where >> unrolling helps specialization (e.g., the subscripts of subscripts in >> the tramp3d example), and check for these patterns explicitely. But this >> is not easy to implement (or to make it robust, and not too >> syntax-dependent). > > Well, one thing is to simply adjust the maximal size increase or see > if honzas improved size heuristics allow to unroll only if the estimated > size does not increase (though for calculix we depend on a very > large estimated size increase IIRC, with the old heuristics at least - there > is a testcase in the testsuite for it).
gfortran.dg/reassoc_4.f, the hottest loop from calculix. Richard.
