[Bug tree-optimization/112361] [14 Regression] avx512f-reduce-op-1.c miscompiled since r14-5076

["rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112361

--- Comment #7 from rguenther at suse dot de <rguenther at suse dot de> ---
On Mon, 6 Nov 2023, rdapp at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112361
> 
> --- Comment #6 from Robin Dapp <rdapp at gcc dot gnu.org> ---
> So "before" we created
> 
>   vect__3.12_55 = MEM <vector(16) float> [(float *)vectp_a.10_53];
>   vect__ifc__43.13_57 = VEC_COND_EXPR <mask__24.9_52, vect__3.12_55, { 0.0,
> 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0 }>;
> //  _ifc__43 = _24 ? _3 : 0.0;
>   stmp__44.14_58 = BIT_FIELD_REF <vect__ifc__43.13_57, 32, 0>;
>   stmp__44.14_59 = r3_29 + stmp__44.14_58;
>   ...
> 
> in vect_expand_fold_left.

Note that this wasn't correct in all cases (wrt signed zeros and
sign-dependent rounding).

> Now, as intended, there is no VEC_COND anymore and we just create the bit-field
> reduction over the unmasked vector.

That's invalid for a COND_OP.  We either have to emulate that COND_OP
by materializing a VEC_COND_EXPR as before when that's semantically
valid, or refrain from vectorizing (I don't think we want to emit
N compare & jump to scalarize the mask effect).

> We could refrain from creating the COND_OP in the first place as Jakub
> mentioned (I guess we know already in if-conv that we shouldn't), re-insert a
> VEC_COND or create a COND_OP chain (instead of an OP chain) in
> vect_expand_fold_left by passing it the mask (and is_cond_op).
> Having several COND_OPs here might make analysis of subsequent passes more
> difficult?

pass in the mask and is_cond_op and create the VEC_COND_EXPR in
vect_expand_fold_left.  But make sure to disallow vectorizing the
invalid cases.