From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 263F838493C2; Tue, 28 Nov 2023 16:28:38 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 263F838493C2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1701188918; bh=Z3Xhb4zHs4ubw7BUV3hRDK5tKuoa4mfRxjx/DbVKotI=; h=From:To:Subject:Date:In-Reply-To:References:From; b=PAxxk4/18cGWlmKGDZK1Vc9tARmcTZIjGdXWKACDvLwvUdvfMX2uD1/Hdct3CsYYk 0qPvwYqbHC7mXqifvwjHmlTjc+qP43SjIcPlb13hw/YR9t1HVfts7iOljTS4s6Ne5i EzFgjGpP4mK5w01hWDESrTIh4qkEeQWi7Z+3Ydk4= From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/112746] Missed optimization for exact division with multi-use addition chain Date: Tue, 28 Nov 2023 16:28:37 +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: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth 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: keywords bug_status everconfirmed short_desc 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 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D112746 Richard Biener changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |missed-optimization Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Summary|Missed optimization for |Missed optimization for |redundancy computation |exact division with |elimination (fre1(tree) for |multi-use addition chain |global variable) | Last reconfirmed| |2023-11-28 --- Comment #1 from Richard Biener --- The issue with test2 is that with value-numbering we have (n.3_1 * 2 + n.3_1) / n.3_1 and that does not simplify. That is, we do not simplify 2 * n + n to 3 * n as in general that wouldn't be profitable if 2 * n is live after the use is elided (and it is live since it's stored to 'b'). Which means we ask for (n.3_1 * 2 + n.3_1) / n.3_1 which we currently cannot simplify to a constant. Handling cases like this in match.pd feels wrong. Note that with -fwrapv the optimization wouldn't be valid. Other passes face the same issue, 'b' keeps n*2 live so an add looks cheaper than to compute n*3 for the division. We're not anticipating the division here. But: _3 =3D n.3_1 + _2; _4 =3D _3 / n.3_1; could be simplified to _5 =3D _2 / n.3_1; _4 =3D _5 + 1; if we know _2 is a multiple of n.3_1 which then could be simplified as well. Note that all passes doing analyses on addition chains also stop at the multi-use, so we'd need to improve at that point somehow.=