From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 57484 invoked by alias); 6 Aug 2018 12:05:00 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 57420 invoked by uid 89); 6 Aug 2018 12:04:59 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=anybody, somebody, tkachov, kyrill X-HELO: mail-yw1-f66.google.com Received: from mail-yw1-f66.google.com (HELO mail-yw1-f66.google.com) (209.85.161.66) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 06 Aug 2018 12:04:57 +0000 Received: by mail-yw1-f66.google.com with SMTP id j68-v6so3480579ywg.1; Mon, 06 Aug 2018 05:04:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=npua8oAtb23R2UI6HZkQ6/a+7wMBDZTOGd8LyFiU12M=; b=KtDFFGTBoidvpXEy8WMWBPAyu6N+O1bQfDGYN393/REDysuYtlMmWuaNNnwtduyM4L dAKnGM+hhE7+2vlEdYGQkbkbiOdGFgyIln+gEK2D/5N+AuAgozCFWOOm40HbLgAScfzL 1QKaisT6nd2C6OCOod58TAW+dVAelbVc8QkyOG40rpmZ+cEeEqUdDRQwF49enkGT1/HE lLpLfD4dPwqukdFpJXuKH+PXeqn5JW1mMqppW2qxBWmgaO6u58hbhVPMYn8ZAyl0z3iU ZLav26duwztuPPXG8jJOdlGP4Kvs1pKARyiTN7ECVGdMCpyiTOsIv4lhJxM+5fppCqtS 3+9w== MIME-Version: 1.0 Received: by 2002:a81:484e:0:0:0:0:0 with HTTP; Mon, 6 Aug 2018 05:04:54 -0700 (PDT) In-Reply-To: References: <5B4DE283.9060100@foss.arm.com> <5B4DF325.2050609@foss.arm.com> <9d0cf3dc-8c5c-bbb2-960c-386b2c936a50@netcologne.de> <5B4F21E0.3060307@foss.arm.com> <2AD7441E-7E57-47EC-9073-92375938B8B8@tkoenig.net> From: Janne Blomqvist Date: Mon, 06 Aug 2018 12:05:00 -0000 Message-ID: Subject: Re: [PATCH][Fortran][v2] Use MIN/MAX_EXPR for min/max intrinsics To: =?UTF-8?Q?Thomas_K=C3=B6nig?= Cc: Kyrill Tkachov , Thomas Koenig , Richard Biener , "fortran@gcc.gnu.org" , GCC Patches Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-SW-Source: 2018-08/txt/msg00396.txt.bz2 On Wed, Jul 18, 2018 at 6:10 PM, Janne Blomqvist wrote: > On Wed, Jul 18, 2018 at 4:26 PM, Thomas K=C3=B6nig wrote: > >> Hi Kyrlll, >> >> > Am 18.07.2018 um 13:17 schrieb Kyrill Tkachov < >> kyrylo.tkachov@foss.arm.com>: >> > >> > Thomas, Janne, would this relaxation of NaN handling be acceptable >> given the benefits >> > mentioned above? If so, what would be the recommended adjustment to the >> nan_1.f90 test? >> >> I would be a bit careful about changing behavior in such a major way. >> What would the results with NaN and infinity then be, with or without >> optimization? Would the results be consistent with min(nan,num) vs >> min(num,nan)? Would they be consistent with the new IEEE standard? >> > > AFAIU, MIN/MAX_EXPR do the right thing when comparing a normal number with > Inf. For NaN the result is undefined, and you might indeed have > > min(a, NaN) =3D a > min(NaN, a) =3D NaN > > where "a" is a normal number. > > (I think that happens at least on x86 if MIN_EXPR is expanded to > minsd/minpd. > > Apparently what the proper result for min(a, NaN) should be is contentious > enough that minnum was removed from the upcoming IEEE 754 revision, and n= ew > operations AFAICS have the semantics > > minimum(a, NaN) =3D minimum(NaN, a) =3D NaN > minimumNumber(a, NaN) =3D minimumNumber(NaN, a) =3D a > > That is minimumNumber corresponds to minnum in IEEE 754-2008 and fmin* in > C, and to the current behavior of gfortran. > > >> In general, I think that min(nan,num) should be nan and that our current >> behavior is not the best. >> > > There was some extensive discussion of that in the Julia bug report I > linked to in an earlier message, and they came to the same conclusion and > changed their behavior. > > >> Does anybody have dats points on how this is handled by other compilers? >> > > The only other compiler I have access to at the moment is ifort (and not > the latest version), but maybe somebody has access to a wider variety? > > >> Oh, and if anything is changed, then compile and runtime behavior should >> always be the same. >> > > Well, IFF we place some weight on the runtime behavior being particularly > sensible wrt NaN's, which it wouldn't be if we just use a plain > MIN/MAX_EXPR. Is it worth taking a performance hit for, though? In > particular, if other compilers are inconsistent, we might as well do > whatever is fastest. > > > -- > Janne Blomqvist > The testcase below (the functions in a separate file to prevent inter-procedural and constant propagation optimizations): program main implicit none real :: a, b =3D 1., mymax, mydiv external mymax, mydiv a =3D mydiv(0., 0.) print *, 'Verify that the following value is a NaN: ', a print *, 'max(', a, ',', b, ') =3D ', mymax(a, b) print *, 'max(', b, ',', a, ') =3D ', mymax(b, a) a =3D mydiv(1., 0.) print *, 'Verify that the following is a Inf: ', a print *, 'max(', a, ',', b, ') =3D ', mymax(a, b) print *, 'max(', b, ',', a, ') =3D ', mymax(b, a) end program main real function mymax(a, b) implicit none real :: a, b mymax =3D max(a, b) end function mymax real function mydiv(a, b) implicit none real :: a, b mydiv =3D a/b end function mydiv With gfortran 6.2 (didn't bother to check other versions as it shouldn't have changed lately) and Intel Fortran 17.0.1 I get the following: % gfortran main.f90 my.f90 && ./a.out Verify that the following value is a NaN: NaN max( NaN , 1.00000000 ) =3D 1.00000000 max( 1.00000000 , NaN ) =3D 1.00000000 Verify that the following is a Inf: Infinity max( Infinity , 1.00000000 ) =3D Infinity max( 1.00000000 , Infinity ) =3D Infinity % gfortran -ffast-math main.f90 my.f90 && ./a.out Verify that the following value is a NaN: NaN max( NaN , 1.00000000 ) =3D NaN max( 1.00000000 , NaN ) =3D 1.00000000 Verify that the following is a Inf: Infinity max( Infinity , 1.00000000 ) =3D Infinity max( 1.00000000 , Infinity ) =3D Infinity % ifort main.f90 my.f90 && ./a.out Verify that the following value is a NaN: NaN max( NaN , 1.000000 ) =3D 1.000000 max( 1.000000 , NaN ) =3D NaN Verify that the following is a Inf: Infinity max( Infinity , 1.000000 ) =3D Infinity max( 1.000000 , Infinity ) =3D Infinity % ifort -fp-model strict main.f90 my.f90 && ./a.out Verify that the following value is a NaN: NaN max( NaN , 1.000000 ) =3D 1.000000 max( 1.000000 , NaN ) =3D NaN Verify that the following is a Inf: Infinity max( Infinity , 1.000000 ) =3D Infinity max( 1.000000 , Infinity ) =3D Infinity For brevity I have omitted tests with various -O[N] optimization levels, which didn't affect the results on either gfortran nor ifort. This suggests that ifort does the equivalent of MAX_EXPR unconditionally. Does anyone have access to other compilers, what results do they give? --=20 Janne Blomqvist