[Bug target/103771] [12 Regression] Missed vectorization under -mavx512f -mavx512vl after r12-5489

["rsandifo at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #18 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
Again haven't really looked at this in detail, so could be wrong, but:

(In reply to rguenther@suse.de from comment #13)
> On Thu, 13 Jan 2022, rsandifo at gcc dot gnu.org wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103771
> > 
> > --- Comment #9 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
> > (In reply to Richard Biener from comment #7)
> > > I think that is what we need to add.  We also don't have a good
> > > representation
> > > for "packing" of masks.
> > > 
> > > diff --git a/gcc/tree-vect-patterns.c b/gcc/tree-vect-patterns.c
> > > index 3ea905538e1..729a1d32612 100644
> > > --- a/gcc/tree-vect-patterns.c
> > > +++ b/gcc/tree-vect-patterns.c
> > > @@ -4679,8 +4679,10 @@ vect_recog_mask_conversion_pattern (vec_info *vinfo,
> > >                                   rhs1_type);
> > >         }
> > >  
> > > -      if (maybe_ne (TYPE_VECTOR_SUBPARTS (vectype1),
> > > -                   TYPE_VECTOR_SUBPARTS (vectype2)))
> > > +      /* AVX512 style masks cannot be packed/unpacked.  */
> > > +      if (TYPE_PRECISION (TREE_TYPE (vectype2)) != 1
> > > +         && maybe_ne (TYPE_VECTOR_SUBPARTS (vectype1),
> > > +                      TYPE_VECTOR_SUBPARTS (vectype2)))
> > >         tmp = build_mask_conversion (vinfo, rhs1, vectype1, stmt_vinfo);
> > >        else
> > >         tmp = rhs1;
> > Haven't had time to look at it properly yet, but my first impression
> > is that that's likely to regress SVE.  Packing and unpacking are
> > natural operations on boolean vector modes.
> 
> Sure, but we can't produce scalar code mimicking this for
> 1 bit element vectors.
Yeah, but at least in the SVE case, we're not aiming to do that.
The vector boolean type that we want to use is recorded in the
STMT_VINFO_VECTYPE of the conversion instead, and doesn't get
recomputed later.

Like you said in the earlier comment, the fact that we can't
do that on scalar code is why this needs to be a vector pattern.

(As discussed elsewhere, it would be good if we didn't commit
vector types early like this.  But in this case I don't think
we can rely on scalar code to model the conversion either.)