Re: [vec-cmp, patch 2/6] Vectorization factor computation

[Richard Biener <richard.guenther@gmail.com>]

On Wed, Oct 14, 2015 at 1:21 PM, Ilya Enkovich <enkovich.gnu@gmail.com> wrote:
> 2015-10-13 16:37 GMT+03:00 Richard Biener <richard.guenther@gmail.com>:
>> On Thu, Oct 8, 2015 at 4:59 PM, Ilya Enkovich <enkovich.gnu@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.
>>