2015-11-13 14:28 GMT+03:00 Richard Biener <richard.guent...@gmail.com>:
> On Fri, Nov 13, 2015 at 11:52 AM, Ilya Enkovich <enkovich....@gmail.com>
> wrote:
>> 2015-11-13 13:38 GMT+03:00 Richard Biener <richard.guent...@gmail.com>:
>>> On Thu, Nov 12, 2015 at 4:44 PM, Ilya Enkovich <enkovich....@gmail.com>
>>> wrote:
>>>> Hi,
>>>>
>>>> Currently compiler may ICE when loaded boolean is compared with vector
>>>> invariant or another boolean value. This is because we don't detect mix
>>>> of bool and non-bool vectypes and incorrectly determine vectype for
>>>> boolean loop invariant for comparison. This was fixed for COND_EXP before
>>>> but also needs to be fixed for comparison. This patch was bootstrapped
>>>> and tested on x86_64-unknown-linux-gnu. OK for trunk?
>>>
>>> Hmm, so this disables vectorization in these cases. Isn't this a
>>> regression? Shouldn't we simply "materialize"
>>> the non-bool vector from the boolean one say, with
>>>
>>> vec = boolvec ? {-1, -1 ... } : {0, 0, 0 ...}
>>
>> We may do this using patterns, but still should catch cases when
>> patterns don't catch it. Patterns don't have vectypes computed and
>> therefore may miss such cases. Thus stability fix is still valid.
>>
>> I don't think we have a compiler version which can vectorize
>> simd-bool-comparison-2.cc, thus technically it is not a regression.
>> There are also other similar cases, e.g. store of comparison result or
>> use loaded boolean as a predicate. I was going to support
>> vectorization for such cases later (seems I don't hit stage1 for them
>> and not sure if it will be OK for stage3).
>
> I still think those checks show that there is an issue we should fix
> differently. We're accumulating more mess into the already messy
> vectorizer :(
Right. Earlier vectype computation would let to reveal such cases more easily.
>
> Ok.
Thanks!
Ilya
>
> Thanks,
> Richard.
>
>> Ilya
>>
>>>
>>> ?
>>>
>>> Thanks,
>>> Richard.
>>>
>>>> Thanks,
>>>> Ilya
