2015-08-26 17:56 GMT+03:00 Richard Biener <richard.guent...@gmail.com>: > On Wed, Aug 26, 2015 at 4:38 PM, Ilya Enkovich <enkovich....@gmail.com> wrote: >> 2015-08-26 16:02 GMT+03:00 Richard Biener <richard.guent...@gmail.com>: >>> On Fri, Aug 21, 2015 at 2:17 PM, Ilya Enkovich <enkovich....@gmail.com> >>> wrote: >>>> 2015-08-21 14:00 GMT+03:00 Richard Biener <richard.guent...@gmail.com>: >>>>> >>>>> Hmm, I don't see how vector masks are more difficult to operate with. >>>> >>>> There are just no instructions for that but you have to pretend you >>>> have to get code vectorized. >>> >>> Huh? Bitwise ops should be readily available. >> >> Right bitwise ops are available, but there is no comparison into a >> vector and no masked loads and stores using vector masks (when we >> speak about 512-bit vectors). >> >>> >>>>> >>>>>> Also according to vector ABI integer mask should be used for mask >>>>>> operand in case of masked vector call. >>>>> >>>>> What ABI? The function signature of the intrinsics? How would that >>>>> come into play here? >>>> >>>> Not intrinsics. I mean OpenMP vector functions which require integer >>>> arg for a mask in case of 512-bit vector. >>> >>> How do you declare those? >> >> Something like this: >> >> #pragma omp declare simd inbranch >> int foo(int*); > > The 'inbranch' is the thing that matters? And all of foo is then > implicitely predicated?
That's right. And a vector version of foo gets a mask as an additional arg. > >>> >>> Well, you are missing the case of >>> >>> bool b = a < b; >>> int x = (int)b; >> >> This case seems to require no changes and just be transformed into vec_cond. > > Ok, the example was too simple but I meant that a bool has a non-conditional > use. Right. In such cases I think it's reasonable to replace it with a select similar to what we now have but without whole bool tree transformed. > > Ok, so I still believe we don't want two ways to express things on GIMPLE if > possible. Yes, the vectorizer already creates only vector stmts that > are supported > by the hardware. So it's a matter of deciding on the GIMPLE representation > for the "mask". I'd rather use vector<bool> (and the target assigning > an integer > mode to it) than an 'int' in GIMPLE statements. Because that makes the > type constraints on GIMPLE very weak and exposes those 'ints' to all kind > of optimization passes. > > Thus if we change the result type requirement of vector comparisons from > signed integer vectors to bool vectors the vectorizer can still go for > promoting that bool vector to a vector of ints via a VEC_COND_EXPR > and the expander can special-case that if the target has a vector comparison > producing a vector mask. > > So, can you give that vector<bool> some thought? Yes, I want to try it. But getting rid of bool patterns would mean support for all targets currently supporting vec_cond. Would it be OK to have vector<bool> mask co-exist with bool patterns for some time? Thus first step would be to require vector<bool> for MASK_LOAD and MASK_STORE and support it for i386 (the only user of MASK_LOAD and MASK_STORE). >Note that to assign > sth else than a vector mode to it needs adjustments in stor-layout.c. > I'm pretty sure we don't want vector BImodes. I can directly build a vector type with specified mode to avoid it. Smth. like: mask_mode = targetm.vectorize.get_mask_mode (nunits, current_vector_size); mask_type = make_vector_type (bool_type_node, nunits, mask_mode); Thanks, Ilya > > Richard. >
