On Tue, 6 Feb 2007, Dorit Nuzman wrote: > > Hi Richard, > > > > > ... > > However..., > > > > I have seen cases in which complete unrolling before vectorization > enabled > > constant propagation, which in turn enabled significant simplification of > > the code, thereby, in fact making a previously unvectorizable loop (at > > least on some targets, due to the presence of divisions, unsupported in > the > > vector unit), into a loop (in which the divisions were replaced with > > constants), that can be vectorized. > > > > Also, given that we are working on "SLP" kind of technology (straight > line > > code vectorization), which would make vectorization less sensitive to > > unrolling, I think maybe it's not such a bad idea after all... One option > > is to increase the default value of --param min-vect-loop-bound for now, > > and when SLP is incorporated, go ahead and schedule early complete > > unrolling. However, since SLP implementation may take some time > (hopefully > > within the time frame of 4.3 though) - we could just go ahead and > schedule > > early complete unrolling right now. (I can't believe I'm in favor of this > > idea, but that loop I was talking about before - improved by a factor > over > > 20x when early complete unrolling + subsequent vectorization were > > applied...) > > > > After sleeping on it, it actually makes a lot of sense to me to schedule > complete loop unrolling before vectorization - I think it would either > simplify loops (sometimes creating more opportunities for vectorization), > or prevent vectorization of loops we probably don't want to vectorize > anyhow, and even that - only temporarily - until we have straight-line-code > vectorization in place. So I'm all for it.
Ok, I'll dig out the patches I had for this and will do some SPEC runs. As soon as I have time for this (no hurry necessary here I think). Thanks! Richard. -- Richard Guenther <[EMAIL PROTECTED]> Novell / SUSE Labs
