This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix ICE for boolean comparison
- From: Ilya Enkovich <enkovich dot gnu at gmail dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 13 Nov 2015 14:31:57 +0300
- Subject: Re: [PATCH] Fix ICE for boolean comparison
- Authentication-results: sourceware.org; auth=none
- References: <20151112154400 dot GE51435 at msticlxl57 dot ims dot intel dot com> <CAFiYyc2FVh0_P88RMmYvPh3N_KP_RscA85t=PN7d1Fo5sgp0-Q at mail dot gmail dot com> <CAMbmDYb4h_MMvKnioEthkdzVV5nJq9PNG+kSTG=CqOVeOtcTGg at mail dot gmail dot com> <CAFiYyc3sOF-Rtu_4x=AsQz_1uzKLL4i8rajEjCKYNQj_db29-A at mail dot gmail dot com>
2015-11-13 14:28 GMT+03:00 Richard Biener <richard.guenther@gmail.com>:
> On Fri, Nov 13, 2015 at 11:52 AM, Ilya Enkovich <enkovich.gnu@gmail.com> wrote:
>> 2015-11-13 13:38 GMT+03:00 Richard Biener <richard.guenther@gmail.com>:
>>> On Thu, Nov 12, 2015 at 4:44 PM, Ilya Enkovich <enkovich.gnu@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