From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id DDB883858016; Mon, 10 Oct 2022 09:49:58 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DDB883858016 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1665395398; bh=j5Q6y8fc6jh7cLf3UNmskLEFt9bpsnqLOnGvWSBz3aI=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Vd7yINUAMJQfD+hN4aGItxf3tGmCB7JQdSo0L3CL4jL5kz3pximFUJd5zQGFn3zEC 0RzttkSrj4WVStEsvzm9TNIP+a+LqoG0IjxbUg9ey7Yvq/57QXnXHeeXT3X1ky6H25 aJRv1Dw1onGdFQbZHmxORomL9xuMo8ZkPu+nSpdk= From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/107096] Fully masking vectorization with AVX512 ICEs gcc.dg/vect/vect-over-widen-*.c Date: Mon, 10 Oct 2022 09:49:56 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Version: 13.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc 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 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D107096 Richard Biener changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ams at gcc dot gnu.org --- Comment #3 from Richard Biener --- (In reply to rsandifo@gcc.gnu.org from comment #2) > See the comment above rgroup_controls in tree-vectorizer.h for the > current assumptions around loop predication. If AVX512 wants something > different then some extensions will be needed :-) Coming back to this now. Crucially If only the first three lanes are active, the masks we need are: f rgroup: 1 1 | 1 1 | 1 1 | 0 0 d rgroup: 1 | 1 | 1 | 0 Here we can use a mask calculated for f's rgroup for d's, but not vice versa. that seems to assume that the space in the mask vector for the "bools" in the d rgroup is twice as large as in that for the f rgroup. For AVX512 there's a single bit for each lane, independently on the width of the actual data. So instead of=20 Thus for each value of nV, it is enough to provide nV masks, with the mask being calculated based on the highest nL (or, equivalently, based on the highest nS) required by any rgroup with that nV. We therefore represent the entire collection of masks as a two-level table, with the first level being indexed by nV - 1 (since nV =3D=3D 0 doesn't exist) and the second being indexed by the mask index 0 <=3D i < nV. we need a set of nV masks for each value of nS, and we can pick the smallest nV for each nS and generate the corresponding larger nV masks by a series of shifts. In fact we can re-use the first vector (excess bits are OK). So for the example in tree-vectorizer.h float *f; double *d; for (int i =3D 0; i < n; ++i) { f[i * 2 + 0] +=3D 1.0f; f[i * 2 + 1] +=3D 2.0f; d[i] +=3D 3.0; } we'd need to perform two WHILE_ULT. For float *f; double *d; for (int i =3D 0; i < n; ++i) { f[i] +=3D 1.0f; d[i] +=3D 3.0; } we'd compute the mask for the f rgroup with a WHILE_ULT and we'll have nV_d =3D 2 * nV_f and the first mask vector from f can be reused for d (but not the other way around). The second mask vector for d can be obtained by kshiftr. There's no other way to do N bit to two N/2 bit hi/lo (un)packing (there's a 2x N/2 bit -> N bit operation, for whatever reason). There's also no way to transform the d rgroup mask into the f rgroup mask for the first example aka duplicate bits in place, { b0, b1, b2, ... bN } -> { b0, b0, b1, b1, b2, b2, ... bN, bN }, nor the reverse. So in reality it seems we need a set of mask vectors for the full set of nS * nV combinations with AVX512. Doing fully masking with AVX2 style vectors would work with the existing rgroup control scheme. Currently the "key" to the AVX512 behavior is the use of scalar modes for the mask vectors but then that's also what GCN uses. Do GCN mask bits really map to bytes to allow the currently used rgroup scheme?=