From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 670D0385741D; Wed, 6 Apr 2022 10:47:32 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 670D0385741D From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/24021] VRP does not work with floating points Date: Wed, 06 Apr 2022 10:47:31 +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: jakub at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: aldyh 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: Wed, 06 Apr 2022 10:47:32 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D24021 --- Comment #24 from Jakub Jelinek --- It would, but it would also give up quite often. For VRP we can do better, because we don't have just the options exactly correct answer or give up, we can have ranges. So, say for flag_rounding_math, we can do real_arithmetics and real_convert= , if inexact or any rounding happens during real_convert, we can ensure that on upper bound we round towards positive infinity and for lower bound towards negative infinity. The flush of denormals can be also handled. And for composite modes, either indeed give up or do something roughly ok too. For math functions have some param with worst ulp error to be used for VRP.= =20 Another case is signed zeros, if it is unsure which zero sign would be used= we can e.g. have a [-0.0, 0.0] range etc. And, it would be nice to have some way to express result is or might be a q= NaN, sNaN, +/- infinity. While the infinities could stand at the end of ranges, so have [5.0, +inf] range, for NaNs it would be nice to know whether the va= lue can or can't be a NaN and even if it has to be NaN, whether it must be a particular NaN or any NaN.=