2015-09-18 15:29 GMT+03:00 Richard Biener <richard.guent...@gmail.com>: > On Tue, Sep 15, 2015 at 3:52 PM, Ilya Enkovich <enkovich....@gmail.com> wrote: >> On 08 Sep 15:37, Ilya Enkovich wrote: >>> 2015-09-04 23:42 GMT+03:00 Jeff Law <l...@redhat.com>: >>> > >>> > So do we have enough confidence in this representation that we want to go >>> > ahead and commit to it? >>> >>> I think new representation fits nice mostly. There are some places >>> where I have to make some exceptions for vector of bools to make it >>> work. This is mostly to avoid target modifications. I'd like to avoid >>> necessity to change all targets currently supporting vec_cond. It >>> makes me add some special handling of vec<bool> in GIMPLE, e.g. I add >>> a special code in vect_init_vector to build vec<bool> invariants with >>> proper casting to int. Otherwise I'd need to do it on a target side. >>> >>> I made several fixes and current patch (still allowing integer vector >>> result for vector comparison and applying bool patterns) passes >>> bootstrap and regression testing on x86_64. Now I'll try to fully >>> switch to vec<bool> and see how it goes. >>> >>> Thanks, >>> Ilya >>> >> >> Hi, >> >> I made a step forward forcing vector comparisons have a mask (vec<bool>) >> result and disabling bool patterns in case vector comparison is supported by >> target. Several issues were met. >> >> - c/c++ front-ends generate vector comparison with integer vector result. >> I had to make some modifications to use vec_cond instead. Don't know if >> there are other front-ends producing vector comparisons. >> - vector lowering fails to expand vector masks due to mismatch of type and >> mode sizes. I fixed vector type size computation to match mode size and >> added a special handling of mask expand. >> - I disabled canonical type creation for vector mask because we can't >> layout it with VOID mode. I don't know why we may need a canonical type >> here. But get_mask_mode call may be moved into type layout to get it. >> - Expand of vec<bool> constants/contstructors requires special handling. >> Common case should require target hooks/optabs to expand vector into >> required mode. But I suppose we want to have a generic code to handle >> vector of int mode case to avoid modification of multiple targets which use >> default vec<bool> modes. > > One complication you might run into currently is that at the moment we > require the comparison result to be > of the same size as the comparison operands. This means that > vector<bool> with, say, 4 elements has > to support different modes for v4si < v4si vs. v4df < v4df (if you > think of x86 with its multiple vector sizes). > That's for the "fallback" non-mask vector<bool> only of course. Does > that mean we have to use different > bool types with different modes here?
I though about boolean types with different sizes/modes. I still avoid them but it causes some ugliness. E.g. sizeof(innertype)*nelems != sizeof(vectortype) for vec<bool>. I causes some special handling in type layout and problems in lowering because BIT_FIELD_REF uses more bits than resulting type has. I use additional comparison to handle it. Richard also proposed to extract one bit only for bools. Don't know if differently sized boolean types may help to resolve this issue or create more problems. > > So the other possibility is to never expose the fallback vector<bool> > anywhere but make sure to lower to > vector<int> via VEC_COND_EXPRs. After all it's only the vectorizer > that should create stmts with > vector<bool> LHS and the vectorizer is already careful to only > generate code supported by the target. In case vec<bool> has integer vector mode, comparison should be handled similar to VEC_COND_EXPR by vect lowering and expand which should be enough to have it properly handled on targets with no vec<bool> support. Thanks, Ilya > >> Currently 'make check' shows two types of regression. >> - missed vector expression pattern recongnition (MIN, MAX, ABX, VEC_COND). >> This must be due to my front-end changes. Hope it will be easy to fix. >> - missed vectorization. All of them appear due to bool patterns disabling. >> I didn't look into all of them but it seems the main problem is in mixed >> type sizes. With bool patterns and integer vector masks we just put >> int->(other sized int) conversion for masks and it gives us required mask >> transformation. With boolean mask we don't have a proper scalar statements >> to do that. I think mask widening/narrowing may be directly supported in >> masked statements vectorization. Going to look into it. >> >> I attach what I currently have for a prototype. It grows bigger so I split >> into several parts. >> >> Thanks, >> Ilya
