public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "linkw at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug target/104015] [12 regression] gcc.dg/vect/slp-perm-9.c fails on power 9 (only) Date: Fri, 14 Jan 2022 10:12:37 +0000 [thread overview] Message-ID: <bug-104015-4-sIlGQ6VOTC@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-104015-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104015 --- Comment #4 from Kewen Lin <linkw at gcc dot gnu.org> --- Hi Andre, Thanks for the detailed explanations all below! (In reply to avieira from comment #3) > Hi Kewen, > > Thanks for the analysis. The param_vect_partial_vector_usage suggestion > seems valid, but that shouldn't be the root cause. > > I would expect an unpredicated V8HI epilogue to fail for a V8HI main loop > (unless the main loop was unrolled). > > That is what the following code in vect_analyze_loop_2 is responsible for: > /* If we're vectorizing an epilogue loop, the vectorized loop either needs > to be able to handle fewer than VF scalars, or needs to have a lower VF > than the main loop. */ > if (LOOP_VINFO_EPILOGUE_P (loop_vinfo) > && !LOOP_VINFO_CAN_USE_PARTIAL_VECTORS_P (loop_vinfo) > && maybe_ge (LOOP_VINFO_VECT_FACTOR (loop_vinfo), > LOOP_VINFO_VECT_FACTOR (orig_loop_vinfo))) > return opt_result::failure_at (vect_location, > "Vectorization factor too high for" > " epilogue loop.\n"); > For this failure rs6000 specific, this check does take effect, but it's too late for this case. Since we already decide to re-try vector modes for epilogue in vect_analyze_loop, the retrying generates one extra unexpected statement in dumping file. Without the culprit commit, it doesn't have any re-tries. According to the comments for the snippet with supports_partial_vectors, I still feel the root cause of this failure is we don't set supports_partial_vectors right on Power9. Since it's considered as true for Power9 but actually no as the partial vector capability also respecting param_vect_partial_vector_usage. if (!supports_partial_vectors && maybe_ge (GET_MODE_NUNITS (vector_modes[mode_i]), first_vinfo_vf)) > So PR103997 is looking at fixing the skipping, because we skip too much now. > You seem to be describing a case where it doesn't skip enough, but like I > said that should be dealt with the code above, so I have a feeling there may > be some confusion here. It seems to me that the case on Power9 even doesn't have a chance to be decided skipped or not. :) > > I have a patch for the earlier bug at > https://gcc.gnu.org/pipermail/gcc-patches/2022-January/588330.html > This is still under review whils we work out a better way of dealing with > the issue. Could you maybe check whether that fixes your failures? I'll > start a cross build for powerpc in the meantime to see if I can check out > these tests. > Thanks for the pointer, I just tried the patch and sorry that it didn't help this failure on rs6000. If my understanding above is correct, it's expected since the patch being reviewed just touched the code guarded with !supports_partial_vectors, while this failed case on Power9 doesn't even enter that block. > As for why I don't use LOOP_VINFO_CAN_USE_PARTIAL_VECTORS_P on the first > loop vinfo to skip epilogue modes, that's because it is possible to have a > non-predicated main loop with a predicated epilogue. The test I added for > aarch64 with that patch is a motivating case. > Thanks for the clarification! On rs6000 it's default with param_vect_partial_vector_usage 1 that the main loop won't use partial vector but the epilogue can use, I'd expect the LOOP_VINFO_CAN_USE_PARTIAL_VECTORS_P of main loop is true if the epilogue can use partial vector. It seems it's different on aarch64.
next prev parent reply other threads:[~2022-01-14 10:12 UTC|newest] Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-01-13 19:47 [Bug target/104015] New: " seurer at gcc dot gnu.org 2022-01-14 3:15 ` [Bug target/104015] " linkw at gcc dot gnu.org 2022-01-14 6:33 ` linkw at gcc dot gnu.org 2022-01-14 8:01 ` rguenth at gcc dot gnu.org 2022-01-14 8:55 ` avieira at gcc dot gnu.org 2022-01-14 10:12 ` linkw at gcc dot gnu.org [this message] 2022-01-14 10:23 ` avieira at gcc dot gnu.org 2022-01-14 10:44 ` rsandifo at gcc dot gnu.org 2022-01-14 11:30 ` avieira at gcc dot gnu.org 2022-01-14 13:04 ` cvs-commit at gcc dot gnu.org 2022-01-14 13:12 ` linkw at gcc dot gnu.org 2022-01-17 12:55 ` rsandifo at gcc dot gnu.org 2022-01-18 3:11 ` linkw at gcc dot gnu.org 2022-01-19 6:04 ` cvs-commit at gcc dot gnu.org 2022-01-19 6:06 ` linkw 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-104015-4-sIlGQ6VOTC@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).