http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50596
--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-10-06 11:57:54 UTC --- Created attachment 25428 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25428 gcc47-vect-condexpr-mixed.patch I believe at least some simple case of bool could be handled in tree-vect-patterns.c by transforming bool lhs assignments with comparison on rhs into COND_EXPRs on char/short/int/long (depending on the comparison operand size), &/|/^ could be handled too and finally either cast to some integer type or memory store). Before trying to write it, I tried to write something simpler, in particular a pattern recognizer that allows to vectorize mixed size type COND_EXPRs (so far only with INTEGER_CST then/else). For the case where COND_EXPR lhs type is wider than comparison type I think it must be INTEGER_CSTs, otherwise we can't ensure that they fit into the narrower integer type. But for lhs type narrower than comparison type lhs = cmp0 < cmp1 ? val1 : val2; (where sizeof (lhs) < sizeof (cmp0)) the above in theory could be transformed into (for itype an integer type with the same sign as val1's type, but size of cmp0) into: val1' = (itype) val1; val2' = (itype) val2; lhs' = cmp0 < cmp1 ? val1' : val2'; lhs = (__typeof (lhs)) lhs'; but we'd need more than one def_stmt for that. This patch allows e.g. vectorization of: float a[1024], b[1024]; unsigned char k[1024]; void foo (void) { int i; for (i = 0; i < 1024; ++i) k[i] = a[i] < b[i] ? -1 : 0; } on i?86/x86_64 which couldn't be previously vectorized. Ira, does this sound reasonable? How should a testcase look like (I think it will be currently only vectorized on i?86/x86_64, as it needs mixed mode vcond support, which, while probably implementable for e.g. altivec, is currently i386 backend only feature)? If this makes sense, I'll try to do the bool pattern recognition next.
