2015-09-23 16:53 GMT+03:00 Richard Biener <richard.guent...@gmail.com>: > On Wed, Sep 23, 2015 at 3:41 PM, Ilya Enkovich <enkovich....@gmail.com> wrote: >> 2015-09-18 16:40 GMT+03:00 Ilya Enkovich <enkovich....@gmail.com>: >>> 2015-09-18 15:22 GMT+03:00 Richard Biener <richard.guent...@gmail.com>: >>>> >>>> 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? 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. >>> >>>> >>>> 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. >>> >>>> >>>> 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. >> >> Hi Richard, >> >> Do you think we have enough confidence approach is working and we may >> start integrating it into trunk? What would be integration plan then? > > I'm still worried about the vec<bool> vector size vs. element size > issue (well, somewhat).
Yeah, I hit another problem related to element size in vec lowering. It uses inner type sizes in expand_vector_piecewise and bool vector expand goes in a wrong way. There were also other places with similar problems and therefore I want to try to use bools of different sizes and see how it goes. Also having different sized bools may be useful to represent masks pack/unpack in scalar code. > > Otherwise the integration plan would be > > 1) put in the vector<bool> GIMPLE type support and change the vector > comparison type IL requirement to be vector<bool>, > fixing all fallout > > 2) get support for directly expanding vector comparisons to > vector<bool> and make use of that from the x86 backend > > 3) make the vectorizer generate the above if supported > > I think independent improvements are > > 1) remove (most) of the bool patterns from the vectorizer > > 2) make VEC_COND_EXPR not have a GENERIC comparison embedded Sounds great! Ilya > > (same for COND_EXPR?) > > Richard. > >> Thanks, >> Ilya
