From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 0BB09385840F; Fri, 9 Feb 2024 10:06:51 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0BB09385840F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1707473211; bh=f2iQYAOwKgZkanuzEEuiOl65DSvjqi7yOFJKIE71i2E=; h=From:To:Subject:Date:In-Reply-To:References:From; b=ulUfdhpZcfDxuN6Vrjm7N18nDE7FIUqr9SF4jz96m4b+x9v3P5KeFG2fBykUxEjl+ DTOjn2YNm2JNGeFmBhOF72fxuNUtnkKJIKyejriL4t0AVS4Edggvmvbc+DhWMOcY1z CzFABNGQv76WKjqQf2lG1GV6uaFTFdpAfzg/3O9I= From: "cvs-commit at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/113774] wrong code with _BitInt() arithmetics at -O2 Date: Fri, 09 Feb 2024 10:06:49 +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: 14.0 X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: cvs-commit 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: --- 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=3D113774 --- Comment #8 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:97e49bf00d1a7b7a2a02531a1c5362fad27348d9 commit r14-8894-g97e49bf00d1a7b7a2a02531a1c5362fad27348d9 Author: Jakub Jelinek Date: Fri Feb 9 11:06:00 2024 +0100 lower-bitint: Attempt not to emit always true conditions in handle_cast [PR113774] The following patch is the optimization part of PR113774, where in handle_cast we emit some conditionals which are always true and presuma= bly VRP would figure that out later and clean it up, except that instead thread1 is invoked and threads everything through the conditions, so we= end up with really ugly code which is hard to be cleaned up later and then run into PR113831 VN bug and miscompile stuff. handle_cast computes low and high as limb indexes, where idx < low doesn't need any special treatment, just uses the operand's limb, idx >=3D high cases all the bits in the limb are an extension (so, for unsigned widening cast all those bits are 0, for signed widening cast all those bits are equal to the in earlier code computed sign mask, narrowing cast don't trigger this code) and then the idx =3D=3D low && = idx < high case if it exists need special treatment (some bits are copied, ot= hers extended, or all bits are copied but sign mask needs to be computed). The code already attempted to optimize away some unneeded casts, in the first hunk below e.g. for the case like 257 -> 321 bit extension, where low is 4 and high 5 and we use a loop handling the first 4 limbs (2 iterations) with m_upwards_2limb 4 - no special handling is needed in t= he loop, and the special handling is done on the first limb after the loop and then the last limb after the loop gets the extension only, or in the second hunk where can emit a single comparison instead of 2 e.g. for the low =3D=3D high case - that must be a zero extension from multiple of limb bits, say 192 -> 328, or for the case where we know the idx =3D=3D low case happens in the other limb processed in the loop= , not the current one. But the testcase shows further cases where we always know some of the comparisons can be folded to true/false, in particular there is 255 -> 257 bit zero extension, so low 3, high 4, m_upwards_2limb 4. The loop handles 2 limbs at the time and for the first limb we were emitting idx < low ? operand[idx] : 0; but because idx goes from 0 with step 2 2 iterations, idx < 3 is always true, so we can just emit operand[idx]. This is handled in the first hunk. In addition to fixing it (that is the " - m_first" part in there) I've rewritten it using low to make it more readable. Similarly, in the other limb we were emitting idx + 1 <=3D low ? (idx + 1 =3D=3D low ? operand[idx] & 0x7ff....ff : operand[idx]) : 0 but idx + 1 <=3D 3 is always true in the loop, so all we should emit is idx + 1 =3D=3D low ? operand[idx] & 0x7ff....ff : operand[idx], Unfortunately for the latter, when single_comparison is true, we emit just one comparison, but the code which fills the branches will fill it with the operand[idx] and 0 cases (for zero extension, for sign extensi= on similarly), not the operand[idx] (aka copy) and operand[idx] & 0x7ff...= .ff (aka most significant limb of the narrower precision) cases. Instead of making the code less readable by using single_comparison for that and handling it in the code later differently I've chosen to just emit a condition which will be always true and let cfg cleanup clean it up. 2024-02-09 Jakub Jelinek PR tree-optimization/113774 * gimple-lower-bitint.cc (bitint_large_huge::handle_cast): Don't emit any comparison if m_first and low + 1 is equal to m_upwards_2limb, simplify condition for that. If not single_comparison, not m_first and we can prove that the idx <= =3D low comparison will be always true, emit instead of idx <=3D low comparison low <=3D low such that cfg cleanup will optimize it = at the end of the pass. * gcc.dg/torture/bitint-57.c: New test.=