From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id BE45C3858004; Mon, 14 Dec 2020 07:21:50 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BE45C3858004 From: "luoxhu at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/22326] promotions (from float to double) are not removed when they should be able to Date: Mon, 14 Dec 2020 07:21:50 +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: 4.1.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: enhancement X-Bugzilla-Who: luoxhu at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 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 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, 14 Dec 2020 07:21:50 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D22326 --- Comment #22 from luoxhu at gcc dot gnu.org --- https://gcc.gnu.org/pipermail/gcc/2020-December/234474.html So this issue seems invalid since "fabs(x)*y+z=E2=80=9D or "fabs(x)+y+z"(x,= y,z are float) could result in -+Inf sometimes, while it won't getting float overfl= ow under double computation. Float value range info is required here. Quoto Richard's reply: I still think that covering all "good" cases in match.pd will require exces= sive matching and that it is better done in a pass (this would include removing the frontend handling for math functions). Note that for example (float)((double)x + (double)y) with float x and y is also eligible to demot= ion to float, likewise may some compositions like (float)(sin((double)x)*cos ((double)y)) for float x and y since we can constrain ranges here. Likewise (float)((double)x + fabs ((double)y)) for float x and y. The propagation would need to stop when the range needed increases in unknown ways.=