From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30105 invoked by alias); 7 Nov 2002 10:04:03 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 30096 invoked from network); 7 Nov 2002 10:04:00 -0000 Received: from unknown (HELO nikam.ms.mff.cuni.cz) (195.113.18.106) by sources.redhat.com with SMTP; 7 Nov 2002 10:04:00 -0000 Received: from camelot.ms.mff.cuni.cz (kampanus.ms.mff.cuni.cz [195.113.18.107]) by nikam.ms.mff.cuni.cz (Postfix) with SMTP id B69BB4E29B; Thu, 7 Nov 2002 11:04:00 +0100 (CET) Received: by camelot.ms.mff.cuni.cz (sSMTP sendmail emulation); Thu, 7 Nov 2002 11:03:59 +0100 Date: Thu, 07 Nov 2002 02:04:00 -0000 From: Jan Hubicka To: Gabriel Dos Reis Cc: Jan Hubicka , Richard Henderson , gcc-patches@gcc.gnu.org, aj@suse.de Subject: Re: Converting floor to rint Message-ID: <20021107100359.GI7964@kam.mff.cuni.cz> References: <20021105173800.GD20534@redhat.com> <20021106092310.GE22059@kam.mff.cuni.cz> <20021106175441.GZ22059@kam.mff.cuni.cz> <20021106180930.GA22066@redhat.com> <20021106211059.GB1316@atrey.karlin.mff.cuni.cz> <20021106222922.GH1316@atrey.karlin.mff.cuni.cz> <20021107092112.GF7964@kam.mff.cuni.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-SW-Source: 2002-11/txt/msg00432.txt.bz2 > Jan Hubicka writes: > > | > Jan Hubicka writes: > | > > | > | On the related note. How bad would you consider converting > | > | floor(x) into rint(x-0.5) in the fast-math mode? > | > > | > If you think you do want to do that transformation, then I would > | > prefer this > | > > | > floor(x) -> nearbyint(x-0.5) > | > > | > | That transformation would do a miracles for i386, where rint is faster > | > | than floor by quite a lot and should suffice for 3D application in > | > | reliablility. I can imagine it to fail only for very large numbers... > | > > | > Not really. floor(1) == 1 and rint(1 - 0.5) maybe be 0 or 1 depending > | > on the current rounding mode. > | Hmm, is rint really expected to be dependent on the rouding mode? > | Man page claims: > | The nearbyint functions round their argument to an integer value > | in floating point format, using the current > | rounding direction and without raising the inexact > | exception. > | > | The rint functions do the same, but will raise the > | inexact exception when the result differs in value > | from the argument. > > The C definition says: > > 7.12.9.3 The nearbyint functions > > Synopsis > > [#1] > > #include > double nearbyint(double x); > float nearbyintf(float x); > long double nearbyintl(long double x); > > Description > > [#2] The nearbyint functions round their argument to an > integer value in floating-point format, using the current > rounding direction and without raising the ``inexact'' > floating-point exception. > > Returns > > [#3] The nearbyint functions return the rounded integer > value. > > 7.12.9.4 The rint functions > > Synopsis > > [#1] > > #include > double rint(double x); > float rintf(float x); > long double rintl(long double x); > > Description > > [#2] The rint functions differ from the nearbyint functions > (7.12.9.3) only in that the rint functions may raise the ^^^ Does this imply that I can implement rint as nearbyint call and never cause the exception and always use frndint instruction for it that does not trap? Honza > ``inexact'' floating-point exception if the result differs > in value from the argument. > > Returns > > [#3] The rint functions return the rounded integer value. > > | I can builtinize nearbyint too if it makes sense. > > Do we have framework to deal correctly with current rounding mode? > I not, I would say, leave it as is until we have the appropriate > machinery. > > | I am bit confused by > | rint. Does it imply that rint will raise exception for any non-integral > | arugment? > > And depending on the rounding mode. > > -- Gaby