From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) by sourceware.org (Postfix) with ESMTPS id 6B46E3858D28 for ; Wed, 25 Jan 2023 00:53:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6B46E3858D28 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=rivosinc.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=rivosinc.com Received: by mail-pg1-x52c.google.com with SMTP id f19so32106pgf.6 for ; Tue, 24 Jan 2023 16:53:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:cc:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=DlZd8M09u6PlftmHBePvKkLlIAhI5SiomekZfN4Vqhc=; b=6U6zY9HmpBZTAku2of7kwduwSo3C30BzszUMZAT1RRhm7LoojQtDjgaeqc7ewD9F2b ghYoNo6rpPuepogBJJ7ZwqTToGX1aSvlNO847DXQyywmLfrqtr8Y5Vjeed2mxyItgSUU azGTvA2F9hkpFv/WlUruSPHzGPFSy3WSeABXLpfWd+vOnFFgjQV4R+v/65IcYRqqntT1 gdiMS3N3b53LZoPOUKh69csRaIDfCVCdjGornOnkKPvitah1YAZcjb4TJXEajBtFhu1k uawd1vvfP7OQYQw1qkoS1yeNcnNB5Z18i3uJUoUEieQ255gfsVFB/GHNj8DmI7YAOhn3 /kLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:cc:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=DlZd8M09u6PlftmHBePvKkLlIAhI5SiomekZfN4Vqhc=; b=oukUvpmjlvUJQSS1bUGqtPCR/acYFP+zIqVH4RC895Bqn8s0NA+imCrbfjHIC9TKYD +tNjRhi2Ncc596kme3WvdZINjkVdleDb4CIkdmEz5ZjjY8gtcrSYfQto/ZRt/nqWyxBy v0igRS08QxLIGLJZLrMp838AHdyQ2pZX01OyLo7SHMG3ztTZ16hQV5PniQ8iWqufs4x5 NTeZX9ePbmTje9098xTNOfsMwzqcjSy4K2pFoDtYnPz0XaEiIbfVF8+Bkvk0XFaQKPDb BqdPMHFzYPGmeclkUZN1I0F5ydVvtR5TQQr9JFEtlY8HrG26yPKtKggU6f3rZPI6yqKf 3+uA== X-Gm-Message-State: AFqh2krfaR2mmSW8LF59LHCZ1vD0SCrC8p4QrDfAAhsg/qGDG8ppcVLz U7MqwVqf79a/L27iRxBy3e1xFOTs7t7Bc2oI X-Google-Smtp-Source: AMrXdXu8BYbCCftg8P4Lo12xSelDEbgB3XUQ+ecR0wEM+nLj5UFWZrPHEyvMtQ3Q0MnYOqM2z+xzoQ== X-Received: by 2002:a62:5e81:0:b0:590:22b:c29d with SMTP id s123-20020a625e81000000b00590022bc29dmr5830983pfb.10.1674608036358; Tue, 24 Jan 2023 16:53:56 -0800 (PST) Received: from [192.168.50.116] (c-24-4-73-83.hsd1.ca.comcast.net. [24.4.73.83]) by smtp.gmail.com with ESMTPSA id v10-20020a056a00148a00b0058da56f8b95sm2209228pfu.115.2023.01.24.16.53.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 24 Jan 2023 16:53:55 -0800 (PST) Message-ID: <97fc2219-d9ff-d808-352c-5e9f97087d66@rivosinc.com> Date: Tue, 24 Jan 2023 16:53:54 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: [RFC] RISC-V: Implement {convert,round}toint() Content-Language: en-US To: Palmer Dabbelt , libc-alpha@sourceware.org References: <20220803174258.4235-1-palmer@rivosinc.com> Cc: gnu-toolchain , Joseph Myers , Szabolcs Nagy , Andrew Waterman From: Vineet Gupta In-Reply-To: <20220803174258.4235-1-palmer@rivosinc.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-9.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,GIT_PATCH_0,KAM_SHORT,NICE_REPLY_A,RCVD_IN_BARRACUDACENTRAL,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 8/3/22 10:42, Palmer Dabbelt wrote: > We currently have fairly inefficient rounding sequences on RISC-V > because we lack direct float->float round instructions. This results in > a bunch of unnecessary handling of FP exceptions in the exp() and pow(). > Luckily TOINT_INTRINSICS seems to exist in order to handle exactly these > problems. > --- > Thanks to Vineet for finding this one. I haven't had a chance to test > it yet, but I figured it'd be best to send this out as an RFC so it > doesn't get lost. > --- > sysdeps/riscv/rvd/math_private.h | 54 ++++++++++++++++++++++++++++++++ > 1 file changed, 54 insertions(+) > create mode 100644 sysdeps/riscv/rvd/math_private.h > > diff --git a/sysdeps/riscv/rvd/math_private.h b/sysdeps/riscv/rvd/math_private.h > new file mode 100644 > index 0000000000..74a5aef07c > --- /dev/null > +++ b/sysdeps/riscv/rvd/math_private.h > @@ -0,0 +1,54 @@ > +/* Configure optimized libm functions. RISC-V version. > + Copyright (C) 2017-2022 Free Software Foundation, Inc. > + This file is part of the GNU C Library. > + > + The GNU C Library is free software; you can redistribute it and/or > + modify it under the terms of the GNU Lesser General Public > + License as published by the Free Software Foundation; either > + version 2.1 of the License, or (at your option) any later version. > + > + The GNU C Library is distributed in the hope that it will be useful, > + but WITHOUT ANY WARRANTY; without even the implied warranty of > + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + Lesser General Public License for more details. > + > + You should have received a copy of the GNU Lesser General Public > + License along with the GNU C Library; if not, see > + . */ > + > +#ifndef RISCV_MATH_PRIVATE_H > +#define RISCV_MATH_PRIVATE_H 1 > + > +#include > +#include > + > +/* Use inline round and lround instructions. */ > +#define TOINT_INTRINSICS 1 > + > +/* The results of these two functions only need to be specified if they can be > + representable in an int32_t. The rounding just has to be consistent with > + each other, here we're using the dynamic rounding mode under the assumption > + that callers avoid changing it. */ > +static inline int32_t > +converttoint (double_t x) > +{ > + int32_t o; > + /* This returns a poorly-formed int32_t when the input exceeds its range. > + That's a pretty hefty use of the unspecified behavior, as it also breaks > + the ABI, but it's slightly faster. */ > + __asm__ ("fcvt.w.d %0, %1" : "=r"(o) : "f"(x)); > + return o; > +} > + > +static inline double_t > +roundtoint (double_t x) > +{ > + double o; > + int32_t i = converttoint(x); > + __asm__ ("fcvt.d.w %0, %1" : "=f"(o) : "r"(i)); > + return o; > +} > + > +#include_next > + > +#endif I gave this a spin (applied to glibc 2.36) but this causes a bunch of additional failures (similar results on both Qemu and Hifive Unmatched). FAIL: math/test-float-ccos FAIL: math/test-float-ccosh FAIL: math/test-float-cexp FAIL: math/test-float-cos FAIL: math/test-float-cpow FAIL: math/test-float-csin FAIL: math/test-float-csinh FAIL: math/test-float-ctan FAIL: math/test-float-ctanh FAIL: math/test-float-sin FAIL: math/test-float-sincos FAIL: math/test-float-tan FAIL: math/test-float32-ccos FAIL: math/test-float32-ccosh FAIL: math/test-float32-cexp FAIL: math/test-float32-cos FAIL: math/test-float32-cpow FAIL: math/test-float32-csin FAIL: math/test-float32-csinh FAIL: math/test-float32-ctan FAIL: math/test-float32-ctanh FAIL: math/test-float32-sin FAIL: math/test-float32-sincos FAIL: math/test-float32-tan regen-ulps doesn't help since the loss of precision if way too high in some cases:     cat workspace/glibc-exp-build/math/test-float-sin.out     ...     Failure: Test: sin_upward (0x8p+0)     Result:     is: 9.89324987e-01 0x1.fa88cep-1     should be: 9.89358306e-01 0x1.fa8d2cp-1     difference: 3.33189965e-05 0x1.178000p-15     ulp : 559.0000     max.ulp : 1.0000 So this will have to wait for the new instructions after all. -Vineet