From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id F0D85389682B; Tue, 19 Jan 2021 09:11:54 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org F0D85389682B From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug testsuite/96109] [11 Regression] gcc.dg/vect/slp-47.c etc. FAIL Date: Tue, 19 Jan 2021 09:11:54 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: testsuite X-Bugzilla-Version: 11.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org X-Bugzilla-Target-Milestone: 11.0 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 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: Tue, 19 Jan 2021 09:11:55 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D96109 Richard Biener changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rsandifo at gcc dot gnu.org --- Comment #5 from Richard Biener --- (In reply to Richard Biener from comment #3) > OK, it's indeed wrong which means we'd fall through the checks that preve= nt > SPARC from vectorizing here but then we'll create an unaligned access > anyway (because VMAT_STRIDED_SLP is too lazy to figure out appropriate > alignment). We're also assuming element alignment there. >=20 > static double x[1024], y[1024]; >=20 > void __attribute__((noipa)) > foo () > { > for (int i =3D 0; i < 511; ++i) > { > x[2*i] =3D y[1022 - 2*i - 1]; > x[2*i+1] =3D y[1022 - 2*i]; > } > } >=20 > int main() > { > for (int i =3D 0; i < 1024; ++i) > x[i] =3D 0, y[i] =3D i; > foo (); > for (int i =3D 0; i < 1022; ++i) > if (x[i] !=3D y[1022 - (i^1)]) > __builtin_abort (); > if (x[1022] !=3D 0 || x[1023] !=3D 0) > __builtin_abort (); > return 0; > } So for example on aarch64-linux with -O3 -mstrict-align -fno-vect-cost-model we analyze this as x.c:6:21: note: vect_model_load_cost: aligned. x.c:6:21: note: vect_model_load_cost: inside_cost =3D 3, prologue_cost = =3D 0 . but correctly emit an unaligned load (dump with -gimple to see the alignmen= t) _20 =3D &y + 8168ul; ... _19 =3D __PHI (__BB5: _16, __BB2: _20); ... _15 =3D __MEM ((double *)_19); and correctly (but not optimal) expand it via extract-bit-field to ;; _15 =3D MEM [(double *)ivtmp_19]; (insn 12 11 13 (clobber (reg:V2DF 95 [ _15 ])) "x.c":8:17 -1 (nil)) (insn 13 12 14 (set (subreg:DI (reg:V2DF 95 [ _15 ]) 0) (mem:DI (reg:DI 92 [ ivtmp.13 ]) [1 MEM [(double *)ivtmp_19]+0 S8 A64])) "x.c":8:17 -1 (nil)) (insn 14 13 0 (set (subreg:DI (reg:V2DF 95 [ _15 ]) 8) (mem:DI (plus:DI (reg:DI 92 [ ivtmp.13 ]) (const_int 8 [0x8])) [1 MEM [(double *)ivtmp_19]+8 S8 A64])) "x.c":8:17 -1 (nil)) so we're not getting a runtime fail here but clearly the vectorizers idea of alignment of the access is bogus (and if VMAT_STRIDED_SLP were less lazy and trusted the computed alignment info we'd miscompile). I guess we're getting away with this because RTL expansion has fallback code to correctly expand misaligned accesses on strict-align targets. But clearly it's not what the vectorizer costs (it also oddly costs a vec_construct when you enable the cost model but doesn't emit any in the en= d).=