From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 953593856B6B; Fri, 9 Dec 2022 15:34:18 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 953593856B6B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1670600059; bh=EaHSMakeuvf1vTumyCir9B85nGVAVybinje1kABEbhs=; h=From:To:Subject:Date:In-Reply-To:References:From; b=gF3kSGOfJ6oNB6tM0OYamxVi8FqNa+/w1ZOJ8w3Gc0hL0KO+c5LbFQLMV/6AT3iAm ANtqzBhsi9078pOjBe02WFSjeodWO4ZBaVJGbBhZlbXdUPi3emCJhf1FDspOd80rBl S9dCCYWso6AYcTHlJIXZkWz0r5a2gzOvHvmmjVYQ= From: "amacleod at redhat dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/107569] [13 Regression] Failure to optimize std::isfinite since r13-3596 Date: Fri, 09 Dec 2022 15:34:15 +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 X-Bugzilla-Severity: normal X-Bugzilla-Who: amacleod at redhat dot com X-Bugzilla-Status: UNCONFIRMED 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=3D107569 --- Comment #43 from Andrew Macleod --- (In reply to Jakub Jelinek from comment #42) > On #c0 foo, this was previously optimized in dom2 which optimized > _4 =3D ABS_EXPR ; > _3 =3D _4 u> 1.79769313486231570814527423731704356798070567525844996599= e+308; > _5 =3D ~_3; > if (_4 u> 1.79769313486231570814527423731704356798070567525844996599e+3= 08) > goto ; [0.00%] > else > goto ; [100.00%] >=20 > [count: 0]: > __builtin_unreachable (); >=20 > [local count: 1073741824]: > return _5; > without any frange related stuff as: > - if (_4 u> 1.79769313486231570814527423731704356798070567525844996599e+= 308) > + if (_3 !=3D 0) > and > - return _5; > + return 1; >=20 > But because __builtin_unreachable () is now removed earlier (vrp1 already; > without providing useful global range though), we don't do that anymore. Hmm. its because when vrp1 removes the branch to builtin_unreachable, it calculates the global range of _4 as the union of all the ranges at each us= e.. this is to avoid issues where the unreachable call may not post-dominate an earlier use. THe initial use of _4 still is resolved to only [0, max] so we end up only using that for the range. Im experimenting with doing things the same way, except NOT removing the br= anch in VRP, but continuing to set the global range the way we do. I might also= be able to revisit the branch *after* all the globals have been set, and see if the globals values now cause the condition to fold, and if they do, remove = them only then...=20=20 ThIs would leave the above case for DOM2 (or someone else to resolve). It seems like it might be a reasonable balance... ie, we only remove the unreachable in VRP1 if we can determine with 100% positivity that setting t= he global value will result in the branch being able to remove. Its also possible it could also just be left... and another pass should rem= ove it shortly as it folds away... and certainly by VRP2 time...=20=20=20 Anyway, I'll try it a few ways and see what seems to work best.=