From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 03213389C41B; Mon, 5 Dec 2022 13:22:10 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 03213389C41B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1670246530; bh=XDyx4CNHuUd2Rmwvx2WzZU/Qf/8x6jTNlKGTJubVjfI=; h=From:To:Subject:Date:In-Reply-To:References:From; b=qhlG47BVY4S1dEXzHYgYdvadixb1S8vyAAmaLSHnHMoMIrT7d+i7lv2kZ2tBGN1ra RveldI1o7eQuZzPZSMYyNzJfsyStDbuinNe0R07ELqd55yF4/GL1XxBOhkwg4SQB/P 6d3xaOxETh95f4QZXWmatYC81Cvw9FKRpEHIWgmQ= From: "aldyh at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/107608] [13 Regression] Failure on fold-overflow-1.c and pr95115.c Date: Mon, 05 Dec 2022 13:22:09 +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: 13.0 X-Bugzilla-Keywords: missed-optimization, wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: aldyh at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 13.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 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D107608 --- Comment #7 from Aldy Hernandez --- (In reply to Richard Biener from comment #6) > (In reply to Jakub Jelinek from comment #0) > > ... but then > > comes dom2 and happily replaces > > _1 =3D 3.4028234663852885981170418348451692544e+38 * 2.0e+0; > > return _1; > > with > > _1 =3D 3.4028234663852885981170418348451692544e+38 * 2.0e+0; > > return Inf; > > (I think this is still correct) >=20 > Note this is also a pessimization code-generation wise since if we > preserve the multiplication the result is readily available in a > register but as optimized we have another constant pool entry and load. >=20 > So we might want to consider not propagating constants generated by > operations > we cannot eliminate. If the only consumer is a compare-and-branch we > can of course still end up with a seemingly dead stmt, so this would be o= nly > for the missed optimization. Up to y'all if this is the way to go, but here are some thoughts... Off the top of my head, we have VRP and DOM propagating constants. Technic= ally also simplify_using_ranges, but it's only called from VRP/DOM, and it curre= ntly only works with integers, so we should be ok here. I think we could limit propagation in may_propagate_copy() which both VRP a= nd DOM gate on. VRP uses it through its use of substitute_and_fold_engine and= DOM uses it directly. Would this work? Would we need to pass an additional argument to may_propagate_copy() (edge = or statement) or can we determine validity by only looking at: bool may_propagate_copy (tree dest, tree orig, bool dest_not_phi_arg_p)=