From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id D2F903858C2B; Tue, 1 Aug 2023 10:40:54 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D2F903858C2B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1690886454; bh=4bgzUMy1ewpDroHAEf2PyW92aLmLcxYfRy4TL1Eueco=; h=From:To:Subject:Date:In-Reply-To:References:From; b=XAIPAL8oa+Y4erXnXpbIszr/a6OKMpEaamWn0HVBTcaBVjJxDgvwBl9HPbrtiA2gy eP5WBaY4+9if7dstVGNLt/WTmPfdZlEeJsBPleFXYZLZ/lzIi4K8GCQVg54LdSAYlU VwNUQa/SzDoh0QNQ5qZ4juopmYBwDTBuQ3xnx1rQ= From: "hubicka at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/106293] [13/14 Regression] 456.hmmer at -Ofast -march=native regressed by 19% on zen2 and zen3 in July 2022 Date: Tue, 01 Aug 2023 10:40:50 +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: 13.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: hubicka at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 13.3 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 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D106293 --- Comment #23 from Jan Hubicka --- Thanks, I think I will need to work out the remaining vectorizer problems. One iss= ue seems to be interaction with loop distribution. Loop distribution seems to intorduce alias checks that are later removed by vectorizer but I suspect t= he profile is not compensated back. Other problem is that lsplit produces loop iterating once (for the last iteration) and does not update loop info accordingly (since it really lacks analysis discovering this). These loops seems to survive into ivopts fast_algorithms.c.182t.ivopts:;; iterations by profile: 5.312499 (unreliab= le, maybe flat) fast_algorithms.c.182t.ivopts:;; iterations by profile: 0.009495 (unreliab= le, maybe flat) fast_algorithms.c.182t.ivopts:;; iterations by profile: 0.009495 (unreliab= le, maybe flat) fast_algorithms.c.182t.ivopts:;; iterations by profile: 0.009495 (unreliab= le, maybe flat) fast_algorithms.c.182t.ivopts:;; iterations by profile: 0.009495 (unreliab= le, maybe flat) fast_algorithms.c.182t.ivopts:;; iterations by profile: 100.000008 (unreliable) fast_algorithms.c.182t.ivopts:;; iterations by profile: 100.000000 (unreliable) fast_algorithms.c.182t.ivopts:;; iterations by profile: 9.662853 (unreliab= le, maybe flat) fast_algorithms.c.182t.ivopts:;; iterations by profile: 4.646072 (unreliab= le) fast_algorithms.c.182t.ivopts:;; iterations by profile: 100.000007 (unreliable) fast_algorithms.c.182t.ivopts:;; iterations by profile: 5.312500 (unreliab= le) fast_algorithms.c.182t.ivopts:;; iterations by profile: 473.497707 (reliab= le) fast_algorithms.c.182t.ivopts:;; iterations by profile: 100.999596 (reliab= le) which is obviously bad idea.=