From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id DDBA3385DC14; Fri, 17 Apr 2020 14:58:46 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DDBA3385DC14 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1587135526; bh=ejO4QYhwzEl6+4wImwyh4iOTLCeOkmDSnJFAbaVJtgQ=; h=From:To:Subject:Date:In-Reply-To:References:From; b=C171nBw+12V5kMqzO1HYtuUljEFI4HM88RTLP1EYhjccJ6Egt+b6em5hb3u4GDKu7 PWzLI1dwJj5MJHi69VnZ/edzDJWTIz8BKkBfKW+g4TEjJsLvkS+DYcxQBBsl5bLfiI UM7vY6fmQRbobB5re4jltN1mnk7i4ESGVsgL7MPE= From: "cvs-commit 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: Fri, 17 Apr 2020 14:58:46 +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: cvs-commit 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: Fri, 17 Apr 2020 14:58:47 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D94567 --- Comment #16 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:1dfc50232dcb703454db4f54c538042a32be2138 commit r10-7773-g1dfc50232dcb703454db4f54c538042a32be2138 Author: Jakub Jelinek Date: Fri Apr 17 16:56:12 2020 +0200 i386: Fix up *testqi_ext_3 define_insn_and_split [PR94567] As the testcase shows, there are unfortunately more problematic cases in *testqi_ext_3 if the mode is not CCZmode, because the sign flag might not behave the same between the insn with zero_extract and what we spli= t it into. The previous fix to the insn condition was because *testdi_1 for mask w= ith upper 32-bits clear and bit 31 set is implemented using SImode test and thus SF is set depending on that bit 31 rather than on always cleared. But we can have other cases. On the zero_extract (which has mode= ), we can have either the pos + len =3D=3D precision of mode, or pos + len < precision of mode cases. The former one copies the m= ost significant bit into SF, the latter will have SF always cleared. For the former case, either it is a zero_extract from a larger mode, but then when we perform test in that larger mode, SF will be always clear = and thus mismatch from the zero_extract case (so we need to enforce CCZmode= ), or it will be a zero_extract from same mode with pos 0 and len equal to mode precision, such zero_extracts should have been really simplified into their first operand. For the latter case, when SF is always clear on the define_insn with zero_extract, we need to split into something that doesn't sometimes set SF, i.e. it has to be a test with mask that doesn't have the most significant bit set. In some cases it can be achieved through using te= st in a wider mode (e.g. in the testcase, there is (zero_extract:SI (reg:HI) (const_int 13) (const_int 3)) which will always set SF to 0, but we split it into (and:HI (reg:HI) (const_int -8)) which will copy the MSB of (reg:HI) into SF, but we can do: (and:SI (subreg:SI (reg:HI) 0) (const_int 0xfff8)) which will keep SF always cleared), but there are various cases where we can't (when already using DImode, or when SImode and we'd turned it into the problematic *testdi_1 implemented using SImode test, or when the val operand is a MEM (we don't want to read from memory more than the user originally wanted), paradoxical subreg of MEM could be problem= atic too if we through the narrowing end up with a MEM). So, the patch attempts to require CCZmode (and not CCNOmode) if it can't really ensure the SF will have same meaning between the define_insn and what we split it into, and if we decide we allow CCNOmode, it needs to avoid performing narrowing and/or widen if pos + len would indicate we'd have= MSB set in the mask. 2020-04-17 Jakub Jelinek Jeff Law PR target/94567 * config/i386/i386.md (*testqi_ext_3): Use CCZmode rather than CCNOmode in ix86_match_ccmode if len is equal to mode precision, or pos + len >=3D 32, or pos + len is equal to operands[2] prec= ision and operands[2] is not a register operand. During splitting perform SImode AND if operands[0] doesn't have CCZmode and pos + len is equal to mode precision. * gcc.c-torture/execute/pr94567.c: New test. Co-Authored-By: Jeff Law =