From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 177F5385781F; Tue, 25 Jan 2022 10:01:23 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 177F5385781F From: "avieira at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug regression/103997] [12 Regression] gcc.target/i386/pr88531-??.c scan-assembler-times FAILs Date: Tue, 25 Jan 2022 10:01:23 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: regression X-Bugzilla-Version: 12.0 X-Bugzilla-Keywords: testsuite-fail X-Bugzilla-Severity: normal X-Bugzilla-Who: avieira at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: unassigned 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: Tue, 25 Jan 2022 10:01:24 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D103997 --- Comment #12 from avieira at gcc dot gnu.org --- Right and did you happen to see a perf increase on these benchmarks with an= y of the patches I mentioned the hash of in the previous comment? Just to explain a bit further what I think is going on. Before my initial patches the epilogue loop analysis would start at the mode_i + 1 of the fir= st loop, in other others, the next mode in the list of modes. After the patch (1) we started this from mode_i =3D 1, so the first mode af= ter VOIDmode, this caused some ICEs if the target didn't add any, not sure about your targets, but that was fixed in (2). In patch (3) Kewen added a fix to my check for potential use of partial vectors, to check the param_vect_partial_vector_usage since that can disable partial vector even if the target supports them. So I suspect that either of these 3 patches inadvertently changed the vectorization strategy for the epilogue of some loop(s) in these benchmarks= . So when I commited patch (4) f4ca0a53be18dfc7162fd5dcc1e73c4203805e14, the vectorization strategy went back to what it was previously. If this is inde= ed what happened then the regression you are seeing is just an indication that= the original vectorization strategy was sub-optimal. This is something that sho= uld be looked at in separate and looked at as an optimization, probably by improving the cost modelling of the vectorizer for your target. Patch 1) commit d3ff7420e941931d32ce2e332e7968fe67ba20af Author: Andre Vieira Date: Thu Dec 2 14:34:15 2021 +0000 [vect] Re-analyze all modes for epilogues Patch 2) commit 016bd7523131b645bca5b5530c81ab5149922743 Author: Andre Vieira Date: Tue Jan 11 15:52:59 2022 +0000 [vect] PR103971, PR103977: Fix epilogue mode selection for autodetect o= nly Patch 3) commit 6d51a9c6447bace21f860e70aed13c6cd90971bd Author: Kewen Lin Date: Fri Jan 14 07:02:10 2022 -0600 vect: Check partial vector param for supports_partial_vectors [PR104015] Patch 4) commit f4ca0a53be18dfc7162fd5dcc1e73c4203805e14 Author: Andre Vieira Date: Wed Jan 19 14:11:32 2022 +0000 vect: Fix epilogue mode skipping=