From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <libc-alpha-return-106614-listarch-libc-alpha=sources.redhat.com@sourceware.org>
Received: (qmail 38577 invoked by alias); 4 Nov 2019 18:22:21 -0000
Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <libc-alpha.sourceware.org>
List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/libc-alpha/>
List-Post: <mailto:libc-alpha@sourceware.org>
List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: libc-alpha-owner@sourceware.org
Received: (qmail 38567 invoked by uid 89); 4 Nov 2019 18:22:21 -0000
Authentication-Results: sourceware.org; auth=none
X-Spam-SWARE-Status: No, score=-9.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=
X-HELO: mail-qt1-f194.google.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google;
        h=to:references:from:openpgp:autocrypt:subject:message-id:date
         :user-agent:mime-version:in-reply-to:content-language
         :content-transfer-encoding;
        bh=fIppTU/mXYSxmy/WwE8bnbSq52mklWsF4GUAyNyLxOc=;
        b=t1o1RfGlFRp6hlUToTXcRcI+PxrxUuzgiGIS8y/UDPC2nhgAa5FZ3k28zbBzsaUeUc
         AKQtiBXjQ+OprbfR4Ge6iXCXg/CEfVsviUVRGVVl+NnjPPwCNWzxvzdIRrLEwNdZ8Ba6
         ulrNnToaaFlJJx3sHlpWcKujYdhL2zjYEtIy1XudEaJVRFepPmaHvKjC/7HSEx4Us5Zp
         zzaFXYFn7KqUuflwL/PSWx91vCuXmDNiH4N46NqoXTenGyoU3xj99AgvDMNOCPCZQD4A
         /NRPkh74ZuHArRBrVIrA86+9lkkoti/cV+6bbWWyAqe3SEMvigzuBO8AX+T+CEoHyGoe
         Rl3g==
Return-Path: <adhemerval.zanella@linaro.org>
To: libc-alpha@sourceware.org
References: <1572881244-6781-1-git-send-email-stli@linux.ibm.com>
From: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Openpgp: preference=signencrypt
Subject: Re: [PATCH 01/17] S390: Use load-fp-integer instruction for nearbyint
 functions.
Message-ID: <fc754475-f2cd-cb07-c527-1ccc567a4868@linaro.org>
Date: Mon, 04 Nov 2019 18:22:00 -0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <1572881244-6781-1-git-send-email-stli@linux.ibm.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-SW-Source: 2019-11/txt/msg00085.txt.bz2



On 04/11/2019 12:27, Stefan Liebler wrote:
> If compiled with z196 zarch support, the load-fp-integer instruction
> is used to implement nearbyint, nearbyintf, nearbyintl.
> Otherwise the common-code implementation is used.

> +
> +double
> +__nearbyint (double x)
> +{
> +  double y;
> +  /* The z196 zarch "load fp integer" (fidbra) instruction is rounding
> +     x to the nearest integer according to current rounding mode (M3-field: 0)
> +     where inexact exceptions are suppressed (M4-field: 4).  */
> +  __asm__ ("fidbra %0,0,%1,4" : "=f" (y) : "f" (x));
> +  return y;
> +}
> +libm_alias_double (__nearbyint, nearbyint)

At least with recent gcc __builtin_nearbyint generates the expected fidbra
instruction for -march=z196.  I wonder if we could start to simplify some
math symbols implementation where new architectures/extensions provide 
direct implementation by a direct mapping implemented by compiler builtins.

I would expect to:

  1. Move all sysdeps/ieee754/dbl-64/wordsize-64 to sysdeps/ieee754/dbl-64/
     since I hardly doubt these micro-optimizations really pay off with
     recent architectures and compiler version.

  2. Add internal macros __USE_<SYMBOL>_BUILTIN and use as:

     * sysdeps/ieee754/dbl-64/s_nearbyint.c
     
     [...]
     double
     __nearbyint (double x)
     {
     #if __USE_NEARBYINT_BUILTIN
       return __builtin_nearbyint (x);
     #else
       /* Use generic implementation.  */
     #endif
     }

  3. Define the __USE_<SYMBOL>_BUILTIN for each architecture.    

It would allow to simplify some architectures, aarch64 for instance.