On Thu, Sep 3, 2015 at 3:57 PM, Ilya Enkovich <enkovich....@gmail.com> wrote: > 2015-09-03 15:11 GMT+03:00 Richard Biener <richard.guent...@gmail.com>: >> On Thu, Sep 3, 2015 at 2:03 PM, Ilya Enkovich <enkovich....@gmail.com> wrote: >>> Adding CCs. >>> >>> 2015-09-03 15:03 GMT+03:00 Ilya Enkovich <enkovich....@gmail.com>: >>>> 2015-09-01 17:25 GMT+03:00 Richard Biener <richard.guent...@gmail.com>: >>>> >>>> Totally disabling old style vector comparison and bool pattern is a >>>> goal but doing hat would mean a lot of regressions for many targets. >>>> Do you want to it to be tried to estimate amount of changes required >>>> and reveal possible issues? What would be integration plan for these >>>> changes? Do you want to just introduce new vector<bool> in GIMPLE >>>> disabling bool patterns and then resolving vectorization regression on >>>> all targets or allow them live together with following target switch >>>> one by one from bool patterns with finally removing them? Not all >>>> targets are likely to be adopted fast I suppose. >> >> Well, the frontends already create vec_cond exprs I believe. So for >> bool patterns the vectorizer would have to do the same, but the >> comparison result in there would still use vec<bool>. Thus the scalar >> >> _Bool a = b < c; >> _Bool c = a || d; >> if (c) >> >> would become >> >> vec<int> a = VEC_COND <a < b ? -1 : 0>; >> vec<int> c = a | d; > > This should be identical to > > vec<_Bool> a = a < b; > vec<_Bool> c = a | d; > > where vec<_Bool> has VxSI mode. And we should prefer it in case target > supports vector comparison into vec<bool>, right? > >> >> when the target does not have vec<bool>s directly and otherwise >> vec<boo> directly (dropping the VEC_COND). >> >> Just the vector comparison inside the VEC_COND would always >> have vec<bool> type. > > I don't really understand what you mean by 'doesn't have vec<bool>s > dirrectly' here. Currently I have a hook to ask for a vec<bool> mode > and assume target doesn't support it in case it returns VOIDmode. But > in such case I have no mode to use for vec<bool> inside VEC_COND > either.
I was thinking about targets not supporting generating vec<bool> (of whatever mode) from a comparison directly but only via a COND_EXPR. > In default implementation of the new target hook I always return > integer vector mode (to have default behavior similar to the current > one). It should allow me to use vec<bool> for conditions in all > vec_cond. But we'd need some other trigger for bool patterns to apply. > Probably check vec_cmp optab in check_bool_pattern and don't convert > in case comparison is supported by target? Or control it via > additional hook. Not sure if we are always talking about the same thing for "bool patterns". I'd remove bool patterns completely, IMHO they are not necessary at all. >> >> And the "bool patterns" I am talking about are those in >> tree-vect-patterns.c, not any targets instruction patterns. > > I refer to them also. BTW bool patterns also pull comparison into > vec_cond. Thus we cannot have SSA_NAME in vec_cond as a condition. I > think with vector comparisons in place we should allow SSA_NAME as > conditions in VEC_COND for better CSE. That should require new vcond > optabs though. I think we do allow this, just the vectorizer doesn't expect it. In the long run I want to get rid of the GENERIC exprs in both COND_EXPR and VEC_COND_EXPR. Just didn't have the time to do this... Richard. > Ilya > >> >> Richard. >> >>>> >>>> Ilya
