On Wed, Oct 14, 2015 at 1:21 PM, Ilya Enkovich <enkovich....@gmail.com> wrote: > 2015-10-13 16:37 GMT+03:00 Richard Biener <richard.guent...@gmail.com>: >> On Thu, Oct 8, 2015 at 4:59 PM, Ilya Enkovich <enkovich....@gmail.com> wrote: >>> Hi, >>> >>> This patch handles statements with boolean result in vectorization factor >>> computation. For comparison its operands type is used instead of restult >>> type to compute VF. Other boolean statements are ignored for VF. >>> >>> Vectype for comparison is computed using type of compared values. Computed >>> type is propagated into other boolean operations. >> >> This feels rather ad-hoc, mixing up the existing way of computing >> vector type and VF. I'd rather have turned the whole >> vector type computation around to the scheme working on the operands >> rather than on the lhs and then searching >> for smaller/larger types on the rhs'. >> >> I know this is a tricky function (heh, but you make it even worse...). >> And it needs a helper with knowledge about operations >> so one can compute the result vector type for an operation on its >> operands. The seeds should be PHIs (handled like now) >> and loads, and yes, externals need special handling. >> >> Ideally we'd do things in two stages, first compute vector types in a >> less constrained manner (not forcing a single vector size) >> and then in a 2nd run promote to a common size also computing the VF to do >> that. > > This sounds like a refactoring, not a functional change, right? Also I > don't see a reason to analyze DF to compute vectypes if we promote it > to a single vector size anyway. For booleans we have to do it because > boolean vectors of the same size may have different number of > elements. What is the reason to do it for other types?
For conversions and operators which support different sized operands > Shouldn't it be a patch independent from comparison vectorization series? As you like. >> >> Btw, I think you "mishandle" bool b = boolvar != 0; > > This should be handled fine. Statement will inherit a vectype of > 'boolvar' definition. If it's invariant - then yes, invariant boolean > statement case is not handled. But this is only because I supposed we > just shouldn't have such statements in a loop. If we may have them, > then using 'vector _Bool (VF)' type for that should be OK. > > Ilya > >> >> Richard. >>
