https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88514
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I think the ICE is for the same reason as why we don't vectorize:
int a[1024];
short int b[1024];
long long c[1024];
void
baz (void)
{
for (int i = 0; i < 1024; i++)
if (a[i] > 10)
c[i] = 5;
}
with -O3 -mavx512{bw,vl,dq} -mprefer-vector-width=256 (or 128).
Unlike the code I've added which uses VEC_{LO,HI}_UNPACK_EXPR on the boolean
vectors directly, vectorizable_conversion checks supportable_widening_operation
and fails because for the vectype_in vector(8) bool and vectype_out vector(4)
bool it can't find an optab. We have vec_unpacks_{lo,hi}_{hi,si,di} optabs
that cover vector(64) bool -> vector(32) bool, vector(32) bool -> vector(16)
bool and vector(16) bool -> vector(8) bool operations. If we added
vec_unpacks_{lo,hi}_qi, it would be ambiguous, whether it is vector(8) bool ->
vector(4) bool or vector(4) bool -> vector(2) bool, so wonder whether we need a
new optab or pass some extra argument to the optab which would tell it the
nunits. The operations we are looking for is really a nop for
vec_unpacks_lo_qi
(so actually don't care about the nunits), the 8 or 4 bit bool vector (mask)
has the right bits in the bottom bits, but we need to use a different shift for
vec_unpacks_hi_qi (either kshiftr{w,b} $4, %kN, %kM or kshiftr{w,b} $2, %kN,
%kM).
