From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 3DDEC3858CDA; Tue, 10 Jan 2023 08:56:58 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3DDEC3858CDA DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1673341018; bh=SoZUEABHBCfIaDcg75MHk1vlQ+2l+H5vhElZAdIFgGY=; h=From:To:Subject:Date:In-Reply-To:References:From; b=WhJMpC9mvxsfnYU8baZeK5kFAgI7gZdqEYwQJOlO6xyVSTGv663HWKxcseHaoUkBD YsH6uuYC/C9QNj+DbAM3NPtA3Bk8DP1IawLfeNHvCRCJYT+XYBpckWd4uQPzssu5ps ShZjUT+fONw7K2thpwEu8cqXuO/fH7fazyn3b8Dg= From: "rguenth 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: Tue, 10 Jan 2023 08:56:58 +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: rguenth 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 #13 from Richard Biener --- (In reply to Aldy Hernandez from comment #12) > (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= only > > for the missed optimization. >=20 > [Sorry for the delayed response. I've been on PTO.] >=20 > For the original testcase, the propagation happens in DOM: >=20 > [local count: 1073741824]: > _1 =3D 3.4028234663852885981170418348451692544e+38 * 2.0e+0; > return _1; >=20 > range_of_expr gets called on the return's _1 and correctly returns Inf, > which allows cprop_operand to do the replacement. >=20 > If I understand correctly you're suggesting not propagating constants that > were generated by an operation we can't eliminate. In this case, it'd be > easy to chase the DEF back to the offending _1 definition (from > cprop_operand and every other places where we do propagations based on > range_of_expr's result), but ranger doesn't keep track of how it got to an > answer, so we'd have to chase all operands used to generate _1?? That'd = get > hairy pretty fast, unless I'm misunderstanding something. Yes, the fact that ranger doesn't operate as a usual propagator with a latt= ice makes things very difficult here. Note that my comment referred to code optimality, not correctness. > It really looks like the problem here is DCE (and the gimplifier as you > point out in comment #2), which is removing a needed statement. Can't th= is > be fixed there? Sure it can, but the expense is that we'd do constant folding all the way down and not remove dead code which will result in _tons_ of unnecessary constant pool entries and loads. The issue is also that -ftrapping-math is default on so we'd have to do this by default. Ugh. Note that the constant folding routines generally refrain from folding when that loses exceptions, it's just ranger when producing singleton ranges and propagating from them that doesn't adhere to that implicit rule.=