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 :( Ok. Thanks, Richard. > Ilya > >> >> ? >> >> Thanks, >> Richard. >> >>> Thanks, >>> Ilya