From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id CC087385DC23; Wed, 15 Apr 2020 16:57:36 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org CC087385DC23 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1586969856; bh=w/E4DM3vq1Qc1oLBl0UEokS2/QINO2ywuajcll2bdek=; h=From:To:Subject:Date:In-Reply-To:References:From; b=s278FH8anVENxaigQwfi1hZnEHlTFDjXL1WPbC3Hwubsd8t5JT+2tTbXr1H477G9n GISxQ1Mpm+5omndP4b3N2IkDlSUhghHPg1tO1YkhPjfIV9bwr9ldFgOuIqhe3Zm4bq dU4egB32QbWvArc6dSX0XpHITZka4vZ4vroPQ1Zk= From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/94567] [10 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu Date: Wed, 15 Apr 2020 16:57:36 +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: 10.0 X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: law at redhat dot com X-Bugzilla-Target-Milestone: 10.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: Wed, 15 Apr 2020 16:57:36 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D94567 Jakub Jelinek changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hubicka at gcc dot gnu.org, | |jakub at gcc dot gnu.org, | |uros at gcc dot gnu.org --- Comment #9 from Jakub Jelinek --- (In reply to Richard Biener from comment #6) > There's also >=20 > && ix86_match_ccmode (insn, > /* *testdi_1 requires CCZmode if the mask has bit > 31 set and all bits above it clear. */ > GET_MODE (operands[2]) =3D=3D DImode > && INTVAL (operands[3]) + INTVAL (operands[4]) = =3D=3D 32 > ? CCZmode : CCNOmode)" >=20 > which is likely where the original correctness issue lies - it fails > to check for the similar cases and HImode (and SImode and QImode). At least in my understanding of this PR, the above addition in PR94088 isn't where the problem is, but the problem is that we shouldn't require CCZmode = just in that case, but also in other cases where the splitting would change the meaning of the sign flag. If (GET_MODE_PRECISION (mode) < INTVAL (operands[3])), then the unspl= it pattern will have SF always false, so we need to ensure that either the pat= tern is using CCZmode in which case we don't care about the sign, or that the ma= sk we'll use doesn't have the most significant bit set. If (GET_MODE_PRECISION (mode) =3D=3D INTVAL (operands[3])), then the = SF will be equal to the most significant bit before splitting. But then we'd need = the resulting insn to use that exact mode, which would mean only trivial zero extraction from position 0 and all bits, combiner should have simplified th= at IMNSHO.=