From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 62E323858401; Fri, 14 Jan 2022 09:40:23 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 62E323858401 From: "rsandifo at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/103771] [12 Regression] Missed vectorization under -mavx512f -mavx512vl after r12-5489 Date: Fri, 14 Jan 2022 09:40:23 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 12.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: rsandifo at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 12.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2022 09:40:23 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D103771 --- Comment #18 from 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: >=20 > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D103771 > >=20 > > --- Comment #9 from 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. > > >=20 > > > 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); > > > } > > >=20=20 > > > - if (maybe_ne (TYPE_VECTOR_SUBPARTS (vectype1), > > > - TYPE_VECTOR_SUBPARTS (vectype2))) > > > + /* AVX512 style masks cannot be packed/unpacked. */ > > > + if (TYPE_PRECISION (TREE_TYPE (vectype2)) !=3D 1 > > > + && maybe_ne (TYPE_VECTOR_SUBPARTS (vectype1), > > > + TYPE_VECTOR_SUBPARTS (vectype2))) > > > tmp =3D build_mask_conversion (vinfo, rhs1, vectype1, stmt_vi= nfo); > > > else > > > tmp =3D 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. >=20 > 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.)=