public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.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 [thread overview] Message-ID: <bug-102905-4-ipvcMtsd15@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-102905-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102905 --- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> --- Hmm, so with a cc1 cross to powerpc64-linux and -mcpu=power7 I do see the correct things in the dump files (but not without -mcpu=power7). 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=E_V4SImode, type=<integer_type 0x7ffff6546738 int>, misalignment=8, is_packed=false) (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 = 1; i <= N; i++) { ia[i] = 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 "vect" { target { { vect_element_align } && { vect_aligned_arrays } } xfail { ! vect_unaligned_possible } } } } */ /* { dg-final { scan-tree-dump-times "Alignment of access forced using peeling" 1 "vect" { xfail vect_element_align_preferred } } } */ so it expects to peel, vectorize the loop but also not vectorize an unaligned 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.
next prev parent reply other threads:[~2021-10-25 9:33 UTC|newest] Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-10-22 18:56 [Bug testsuite/102905] New: " seurer at gcc dot gnu.org 2021-10-22 21:20 ` [Bug testsuite/102905] " pinskia at gcc dot gnu.org 2021-10-25 6:40 ` [Bug tree-optimization/102905] " rguenth at gcc dot gnu.org 2021-10-25 9:33 ` rguenth at gcc dot gnu.org [this message] 2021-10-25 10:49 ` cvs-commit at gcc dot gnu.org 2021-10-25 10:49 ` rguenth at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-102905-4-ipvcMtsd15@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).