From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 603B8385DC1B; Wed, 15 Apr 2020 17:48:32 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 603B8385DC1B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1586972912; bh=lfLLp4BbF3QROhn3N0fUEvj0tx9N7NuP5/DvK8C0IXc=; h=From:To:Subject:Date:In-Reply-To:References:From; b=NPPvFdNrpIaC9ZEgAUywRo1oHjeuNFvh+ReVdyQPsOVPqDDQJO9ytKQmi4nBzvlzJ Gasa6zxUeP8YC8+tZIn7iioJhMuXnfrQmV0fJrbxTtNpbxZROPNjO0bIeL1QZKpxCm n3tGhrOYglAtXbTRlfz35w38yK5GfS8+N34L6AK4= 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 17:48:32 +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: 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 17:48:32 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D94567 --- Comment #12 from Jakub Jelinek --- (In reply to Jeffrey A. Law from comment #11) > Rather than extending that hack, I think just widening the mode when the > sign bit is being tested (c#5) is simpler and easier to understand. The > bits you're changing should be killed rather than extended to handle more > cases. That is not a hack. x86_64 doesn't have an instruction that ands a 64-bit reg/mem with a 32-bit zero extended immediate (nor 64-bit immediate), so wh= en we want to use reg against 32-bit zero extended, we need to use 32-bit instruction and that has different behavior for the SF, so we must ensure we don't care about that most significant bit. Now for these other cases, perhaps we could instead user wider mode if possible, but it isn't possible always. So, combine my patch with the last condition changed into >=3D 32 from =3D=3D GET_MODE (operands[2]) and then apply what you have in #c5, but with hardcoded SImode instead of wider mode - we want to avoid introducing HImode stuff when there wasn't before, it is both larger and slower - and only do = it if GET_MODE (operands[0]) isn't CCZmode. If pos + len >=3D 32, such in the pos + len =3D=3D 64 special case where we= turn testing bits pos (< 32) up to most significant into a testq which has that sign-extended 32-bit immediate, then the pattern before splitting would have always SF zero (unless pos is 0) but split pattern would always copy there = the MSB of the 64-bit register.=