This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [vec-cmp, patch 2/6] Vectorization factor computation
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Ilya Enkovich <enkovich dot gnu at gmail dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 20 Oct 2015 15:45:00 +0200
- Subject: Re: [vec-cmp, patch 2/6] Vectorization factor computation
- Authentication-results: sourceware.org; auth=none
- References: <20151008145948 dot GC63757 at msticlxl57 dot ims dot intel dot com> <CAFiYyc3uebeRtxhbkyRX43xQ2jCK6cfJg8Y=a20HVa0s2_FK6w at mail dot gmail dot com> <CAMbmDYb0OjQ5__kUhdjdn6ygnm4Sg7deCG_Nnkpwki2yBD=Tnw at mail dot gmail dot 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.
>>