From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 617F5385E020; Mon, 10 Aug 2020 09:49:27 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 617F5385E020 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1597052967; bh=JxRMLQH2nq2+r63m9vsJyUx4HqWpn83LfV3kpzTcSc4=; h=From:To:Subject:Date:In-Reply-To:References:From; b=P849wNxoPF8PSuCHFUxLmh0XFPFX6Wzfcwmxd7rymj3qmCva4cEDdfGx9ltkgyCLU aTpLfPjB6+M8BDouYsI8nlqbWJc+uBswM20a2Sy84PUjXrsCSJrJd576qA29qJQr4u 0oztrqYD8qgrOLH4ppx222LdeLRnlIAi+kYzT9go= From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/96542] Failure to optimize simple code to a constant when storing part of the operation in a variable Date: Mon, 10 Aug 2020 09:49:27 +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: 11.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub 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: everconfirmed cc bug_status cf_reconfirmed_on 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: Mon, 10 Aug 2020 09:49:27 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D96542 Jakub Jelinek changed: What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 CC| |jakub at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed| |2020-08-10 --- Comment #1 from Jakub Jelinek --- unsigned char foo (unsigned int x) { _Bool y =3D x; return (((unsigned char) ~0) >> y) * 2; } unsigned char bar (unsigned int x) { return (((unsigned char) ~0) >> (_Bool) x) * 2; } In bar, this is optimized, because fold_binary_op_with_conditional_arg optimizes 255 >> (x ? 1 : 0) into x ? 127 : 255 and when multiplied by two in unsigned char this results in x ? 254 : 254. We don't have anything comparable in match.pd yet I believe (and should we?= ). Or shall say VRP try harder if it sees [0, 1] ranges? Though, shouldn't we optimize e.g. unsigned baz (unsigned int x) { if (x >=3D 4) return 32; return (-1U >> x) * 16; } too to return x >=3D 4 ? 32U : -16U; ? Not sure where and how to generalize it though. Value range of -1U >> [0, 3] is not really useful here, nonzero bits either. And having a specialized (const1 >> x) * const2 optimizer based on x's value range would work, but not sure if it has a real-world benefit.=