From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 4EA543858D35; Wed, 29 Dec 2021 14:48:50 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4EA543858D35 From: "fxcoudert at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/91690] Slow IEEE intrinsics Date: Wed, 29 Dec 2021 14:48:50 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Version: 9.2.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: fxcoudert 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: cc 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, 29 Dec 2021 14:48:50 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D91690 Francois-Xavier Coudert changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fxcoudert at gcc dot gnu.o= rg --- Comment #8 from Francois-Xavier Coudert = --- I think things are a little more complicated that they appear. The function IEEE_IS_NAN, in itself, is not the problem: it is not slow, and does not store/restore the floating-point state. If you take the demo program, and replace the call to the contained function IS_NAN_IEEE directly by the IEEE_IS_NAN function, you will actually see that it is faster (50% faster) = than the bit-checking function. The problem is in the contained function IS_NAN_IEEE. By my reading of the Fortran standard, that function is required to save its floating-point stat= e on entry, and restore it on exit. This is regardless of what happens inside the function, and this is what is slowing things done. Of course, we can still consider this a "missed optimisation": the compiler could in theory determine that absolutely no floating-point operation is be= ing done, and optimise away the save/restore calls. But it is a tricky thing to= do, and would have no value for "real" functions, that actually perform floating-point operations.=