From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 77DE73858407; Fri, 24 Sep 2021 07:50:11 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 77DE73858407 From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/102473] [12 Regression] 521.wrf_r 5% slower at -Ofast and generic x86_64 tuning after r12-3426-g8f323c712ea76c Date: Fri, 24 Sep 2021 07:50:11 +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: rguenth 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: 12.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc 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, 24 Sep 2021 07:50:11 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D102473 Richard Biener changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |marxin at gcc dot gnu.org --- Comment #3 from Richard Biener --- (In reply to Hongtao.liu from comment #2) > (In reply to Richard Biener from comment #1) > > Looks like at least on Zen movs[hl]dup is on the integer domain so we'l= see > > a domain crossing penalty here(?). But since this is a generic arch/tu= ning > > regression the SSE2 code path should be what matters - on the committed > > testcase I see > >=20 > > foo: > > .LFB572: > > .cfi_startproc > > pxor %xmm0, %xmm0 > > addss (%rdi), %xmm0 > > addss 4(%rdi), %xmm0 > > addss 8(%rdi), %xmm0 > > addss 12(%rdi), %xmm0 > > ret > >=20 > > where it seems that the vectorizer doesn't pick up the reduction patter= n. > >=20 > Guess you're use O3, -ffast-math is needed for v4sf reduction > https://godbolt.org/z/sjf4Pncna I was looking at the testcase as compiled by the testsuite. It seems that adding __attribute__((optimize("tree-vectorize"))) makes the loop no longer vectorized as it at the moment cancels -ffast-math. IIRC when Martin commits his optimize() re-org it will no longer do that.=