From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from elaine.keithp.com (home.keithp.com [63.227.221.253]) by sourceware.org (Postfix) with ESMTPS id 8C86D394743A for ; Mon, 7 Sep 2020 17:16:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 8C86D394743A Received: from localhost (localhost [127.0.0.1]) by elaine.keithp.com (Postfix) with ESMTP id 13E2D3F2D6BB; Mon, 7 Sep 2020 10:16:25 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at keithp.com Received: from elaine.keithp.com ([127.0.0.1]) by localhost (elaine.keithp.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 9z3S7Mq9VfaF; Mon, 7 Sep 2020 10:16:24 -0700 (PDT) Received: from keithp.com (koto.keithp.com [10.0.0.2]) by elaine.keithp.com (Postfix) with ESMTPSA id AEE633F2D6B1; Mon, 7 Sep 2020 10:16:24 -0700 (PDT) Received: by keithp.com (Postfix, from userid 1000) id 939051582201; Mon, 7 Sep 2020 10:16:24 -0700 (PDT) From: "Keith Packard" To: Eric Bresie , "newlib\@sourceware.org" Subject: Re: Re: [PATCH 0/3] ARM with only 32-bit floats do not have fast 64-bit FMA In-Reply-To: <91e9c460-6029-445f-bab5-c180372ff7aa@iPad> References: <91e9c460-6029-445f-bab5-c180372ff7aa@iPad> Date: Mon, 07 Sep 2020 10:16:24 -0700 Message-ID: <874ko95wyf.fsf@keithp.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: newlib@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Newlib mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2020 17:16:45 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Eric Bresie via Newlib writes: > Not directly related (and as I=E2=80=99m not really an expert on these th= ings, nor able to change in any way) but was looking at the code mentioned = and saw line like: > > if (x =3D=3D 0.0 || y =3D=3D 0.0) > > return (x * y + z); > > If either x or y is zero would it be better to just return z and avoid > an extra multiplication operation here? You want to compute the correct result and get the right exceptions in all of the delightful IEEE754 corner cases (e.g. 0 =C3=97 =E2=88=9E). It's = easier to just execute the two operations than to try and synthesize the right result (which is implementation-dependent in the case of 0 =C3=97 =E2=88=9E= + qNaN). The key here is that if x or y is zero, then you won't lose any intermediate precision by performing the operation this way. =2D-=20 =2Dkeith --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEw4O3eCVWE9/bQJ2R2yIaaQAAABEFAl9WaugACgkQ2yIaaQAA ABF+0A/8DtvyoGyCu/6iUaGUd5AuWF4qr62Fh9/s9LXacLuHaH2M2oK8UGNJNNYs 0j83/jTUkio8JdMjhtmU28jNwaY+/yo/M38it6LK9jQ6KyEy/t5hkUBs8Ty4o1Ln hL0/Oq7M4VI37w5gaIzU9jirzEv0AQwOChfOCvNWfrugXEPWP3URI5niwKXis8nI Vs/bovhx1gxAKo2DfPQ05+GJ7mMuuUaU/NnrSZj2M+OmeOyGgWGFkWjeRWOQciim 6NGIsY+CBdq/0jGiXidKZxgbXz8DswINTAcsCKzZSaHoBRl9ok1a9HNGgPmbnV13 XpqCb5ImHN7mKeVJl6wMGt6GMHd1cVmGQAEnpaNKo60mSdHdyQZky8sGjPBaz2k7 maQ56ONVF/1yiZZQa2JGTbvHcPiLiVW7tmp0pQT9pqVbI9Y7sI9GnevPoUkQxSgq JmcJLUHloirstYSBj5tnre+63WI9c9cv8wohBXf0Vemf+7DKYxl5pA2KEf0h48PI hVz4evz7ZztCXcKFZflDQ1AFT+MTvzCcRdLpNQ7HCwG2kWcbzCjGKK9Z/D7UoxhD WLJx9E7HGLMzoz09B4zcIpr/ajFPEmaZ8zGTeohVACx/RG3OWFctxSIzAxx3FCwT djT8+94ik70h/9z09SUReW1mjowh2lWQbMqlmSVdGlBUIEe+TkY= =w10w -----END PGP SIGNATURE----- --=-=-=--