From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 5A209385AC34; Fri, 14 Jan 2022 10:12:37 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5A209385AC34 From: "linkw at gcc dot 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 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 12.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: linkw at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: linkw 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: Fri, 14 Jan 2022 10:12:37 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D104015 --- Comment #4 from Kewen Lin --- Hi Andre, Thanks for the detailed explanations all below! (In reply to avieira from comment #3) > Hi Kewen, >=20 > Thanks for the analysis. The param_vect_partial_vector_usage suggestion > seems valid, but that shouldn't be the root cause. >=20 > I would expect an unpredicated V8HI epilogue to fail for a V8HI main loop > (unless the main loop was unrolled). >=20 > 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 ne= eds > 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"); >=20 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 epil= ogue 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 n= ow. > 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 dec= ided skipped or not. :) >=20 > I have a patch for the earlier bug at > https://gcc.gnu.org/pipermail/gcc-patches/2022-January/588330.html=20 > 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.=20 >=20 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 en= ter 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. >=20 Thanks for the clarification! On rs6000 it's default with param_vect_partial_vector_usage 1 that the main loop won't use partial vect= or 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.=