On Fri, Sep 18, 2015 at 3:40 PM, Ilya Enkovich <enkovich....@gmail.com> wrote: > 2015-09-18 15:22 GMT+03:00 Richard Biener <richard.guent...@gmail.com>: >> 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. > > Where may these direct comparisons come from? Vectorizer never > generates unsupported statements. It means we get them from > gimplifier?
That's what I say - the vecotirzer wouldn't generate them. > So touch optabs in gimplifier to avoid direct comparisons? > Actually vect lowering checks if we are able to make comparison and > expand also uses vec_cond to expand vector comparison, so probably we > may live with them. > >> >>> 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. > > I refer to transformations made by vect_recog_bool_pattern. Don't see > how to remove them completely for targets not supporting comparison > vectorization. The vectorizer can vectorize comparisons by emitting a VEC_COND_EXPR (the bool pattern would turn the comparison into a COND_EXPR). I don't see how the pattern intermediate step is necessary. The important part is to get the desired vector type of the comparison determined. >> >>>> >>>> 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... > > That would be nice. As a first step I'd like to support optabs for > VEC_COND_EXPR directly using vec<bool>. > > Thanks, > Ilya > >> >> Richard. >> >>> Ilya >>> >>>> >>>> Richard. >>>> >>>>>> >>>>>> Ilya
