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. 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. > > 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. Ilya > > Richard. > >>> >>> Ilya
