> For the fortran testcase we don't even run into this but hit an > internal def and assert on > > gcc_assert (STMT_VINFO_VEC_STMTS (def_stmt_info).length () == ncopies); > > I think this shows missing handling of .COND_* in the bool pattern recognition > as we get the 'bool' condition as boolean data vector rather than a mask. The > same is true for the testcase with the invariant condition. This causes us to > select the wrong vector type here. The "easiest" might be to look at > how COND_EXPR is handled in vect_recog_bool_pattern and friends and > handle .COND_* IFNs the same for the mask operand.
For the first (imagick) testcase adding a bool pattern does not help because we always pass NULL as vectype to vect_get_vec_defs. Doing so we will always use get_vectype_for_scalar_type (i.e. a "full" bool vector) because vectype of the (conditional) stmt is the lhs type and not the mask's type. For cond_exprs in vectorizable_condition we directly pass a comp_vectype instead (truth_type). Wouldn't that, independently of the pattern recog, make sense? Now for the Fortran testcase I'm still a bit lost. Opposed to before we now vectorize with a variable VF and hit the problem in the epilogue with ncopies = 2. .COND_ADD (_7, __gcov0.__brute_force_MOD_brute_I_lsm.21_67, 1, __gcov0.__brute_force_MOD_brute_I_lsm.21_67); where _7 = *_6 which is an internal_def. I played around with doing it analogously to the COND_EXPR handling, so creating a COND_ADD (_7 != 0) which will required several fixups in other places because we're not prepared to handle that. In the end it seems to only shift the problem because we will still need the definition of _7. I guess you're implying that the definition should have already been handled by pattern recognition so that at the point when we need it, it has a related pattern stmt with the proper mask type? Regards Robin
