On Mon, Nov 9, 2015 at 2:54 PM, Ilya Enkovich <enkovich....@gmail.com> wrote: > 2015-10-20 16:45 GMT+03:00 Richard Biener <richard.guent...@gmail.com>: >> 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 > > That's what we handle in vector patterns and use some helper functions > to determine vectypes there. Looks like this refactoring would affects > patterns significantly. Probably compute vectypes before searching for > patterns? > >> >>> Shouldn't it be a patch independent from comparison vectorization series? >> >> As you like. > > I'd like to move on with vector comparison and consider VF computation > refactoring when it's stabilized. This patch is the last one (except > target ones) not approved in all vector comparison related series. > Would it be OK to go on with it in a current shape?
Yes. Thanks, Richard. > Thanks, > Ilya
