On Wed, Aug 26, 2015 at 5:51 PM, Ilya Enkovich <enkovich....@gmail.com> wrote: > 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?
No, I'd like to remove the bool patterns anyhow - the vectorizer should be able to figure out the correct vector type (or mask type) from the uses. Currently it simply looks at the stmts LHS type but as all stmt operands already have vector types it can as well compute the result type from those. We'd want to have a helper function that does this result type computation as I figure it will be needed in multiple places. This is now on my personal TODO list (but that's already quite long for GCC 6), so if you manage to get to that... see tree-vect-loop.c:vect_determine_vectorization_factor which computes STMT_VINFO_VECTYPE for all stmts but loads (loads get their vector type set from data-ref analysis already - there 'bool' loads correctly get VNQImode). There is a basic-block / SLP part as well that would need to use the helper function (eventually with some SLP discovery order issue). > 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). You can certainly try that first, but as soon as you hit complications with needing to adjust bool patterns then I'd rather get rid of them. >>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); Hmm, indeed, that might be a (good) solution. Btw, in this case target attribute boundaries would be "ignored" (that is, TYPE_MODE wouldn't change depending on the active target). There would also be no way for the user to declare vector<bool> in source (which is good because of that target attribute issue...). So yeah. Adding a tree.c:build_truth_vector_type (unsigned nunits) and adjusting truth_type_for is the way to go. I suggest you try modifying those parts first according to this scheme that will most likely uncover issues we missed. Thanks, Richard. > Thanks, > Ilya > >> >> Richard. >>
