> 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. dorit > dorit > > > > Thanks, > > Richard. > > > > -- > > Richard Guenther <[EMAIL PROTECTED]> > > Novell / SUSE Labs >
