From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 1E8EE3858C27; Mon, 25 Oct 2021 09:33:05 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1E8EE3858C27 From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/102905] [12 regression] several vector test cases fail on power 7 after r12-4490 Date: Mon, 25 Oct 2021 09:33:05 +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: 12.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: 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: Mon, 25 Oct 2021 09:33:05 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D102905 --- Comment #2 from Richard Biener --- Hmm, so with a cc1 cross to powerpc64-linux and -mcpu=3Dpower7 I do see the correct things in the dump files (but not without -mcpu=3Dpower7). Similar behavior is for -mvsx vs. -mno-vsx (where it also reproduces on ppc64le) In the failing case we ask the target rs6000_builtin_support_vector_misalignment (mode=3DE_V4SImode,=20 type=3D, misalignment=3D8, is_packed= =3Dfalse) (that's the store) but w/o TARGET_VSX that function simply returns false. The source of the testcase (vect-peel-1.c) specifically says /* All the accesses are misaligned. With cost model disabled, we count the number of aligned accesses for each peeling option, and in this case we align the two loads if possible (i.e., if misaligned stores are supported). */ for (i =3D 1; i <=3D N; i++) { ia[i] =3D ib[i+2] + ib[i+6]; and that's what seems to happen. But then the testcase has /* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" } } */ /* { dg-final { scan-tree-dump-times "Vectorizing an unaligned access" 1 "v= ect" { target { { vect_element_align } && { vect_aligned_arrays } } xfail { ! vect_unaligned_possible } } } } */ /* { dg-final { scan-tree-dump-times "Alignment of access forced using peel= ing" 1 "vect" { xfail vect_element_align_preferred } } } */ so it expects to peel, vectorize the loop but also not vectorize an unalign= ed accesss? Ah, so before the change we peeled 3 iterations, aligning the store which means we were able to use re-aligning loads. But now we are peeling 1 iteration to align the loads (as the testcase expected). And the key difference is that we're now invoking the target hook to tell whether vect_peeling_hash_insert should boost the entry but formerly we used vect_supportable_dr_alignment which had the re-align load path. But after later refactoring we can now again easily use vect_supportable_dr_alignment here.=