On Wed, Aug 26, 2015 at 3:35 PM, Jakub Jelinek <ja...@redhat.com> wrote: > On Wed, Aug 26, 2015 at 03:21:52PM +0200, Richard Biener wrote: >> On Wed, Aug 26, 2015 at 3:16 PM, Jakub Jelinek <ja...@redhat.com> wrote: >> > On Wed, Aug 26, 2015 at 03:02:02PM +0200, Richard Biener wrote: >> >> > AVX-512 is such target. Current representation forces multiple scalar >> >> > mask -> vector mask and back transformations which are artificially >> >> > introduced by current bool patterns and are hard to optimize out. >> >> >> >> I dislike the bool patterns anyway and we should try to remove those >> >> and make the vectorizer handle them in other ways (they have single-use >> >> issues anyway). I don't remember exactly what caused us to add them >> >> but one reason was there wasn't a vector type for 'bool' (but I don't see >> >> how >> >> it should be necessary to ask "get me a vector type for 'bool'"). >> > >> > That was just one of the reasons. The other reason is that even if we >> > would >> > choose some vector of integer type as vector of bool, the question is what >> > type. E.g. if you use vector of chars, you almost always get terrible >> > vectorized code, except for the AVX-512 you really want an integral type >> > that has the size of the types you are comparing. >> >> Yeah, but the way STMT_VINFO_VECTYPE is computed is that we always >> first compute the vector type for the comparison itself (which is "fixed") >> and >> thus we can compute the vector type of any bitwise op on it as well. > > Sure, but if you then immediately vector narrow it to a V*QI vector because > it is stored originally into a bool/_Bool variable, and then again when it > is used in say a COND_EXPR widen it again, you get really poor code. > So, what the bool pattern code does is kind of poor man's type > promotion/demotion pass for bool only, at least for the common cases.
Yeah, I just looked at the code but in the end everything should be fixable in the place we compute STMT_VINFO_VECTYPE. The code just looks at the LHS type plus at the narrowest type (for vectorization factor). It should get re-structured to get the vector types from the operands (much like code-generation will eventually fall back to). > PR50596 has been the primary reason to introduce the bool patterns. > If there is a better type promotion/demotion pass on a copy of the loop, > sure, we can get rid of it (but figure out also what to do for SLP). Yeah, of course. Basic-block SLP just asks for the vectype during SLP analysis AFAIK. I suppose we want sth like get_result_vectype (gimple) which can look at operands as well and can be used from both places. After all we do want to fix the non-single-use issue somehow and getting rid of the patterns sounds good to me anyway... Not sure if I can get to the above for GCC 6, but at least putting it on my TODO... Richard. > Jakub
