From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from fossa.birch.relay.mailchannels.net (fossa.birch.relay.mailchannels.net [23.83.209.62]) by sourceware.org (Postfix) with ESMTPS id 9CC17385773A for ; Fri, 21 Apr 2023 11:21:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9CC17385773A Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=gotplt.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gotplt.org X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 4EBAD261B6C; Fri, 21 Apr 2023 11:20:58 +0000 (UTC) Received: from pdx1-sub0-mail-a305.dreamhost.com (unknown [127.0.0.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id D0C4F261D09; Fri, 21 Apr 2023 11:20:57 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1682076057; a=rsa-sha256; cv=none; b=BV7gIY7wpdnj4alE9VpN0hFhUh15/Nkawqd0BaMYQ0IhtUN4wFFCu8dC04kbNtL0FK18BA PRQjbMQF/yH3oAEB0gCK09Iss3QtYmc7C7nQmzHML3WIrd8PH9HnTsZ/C9e6h6CzEQruDC Dvu8eRi2+7nAVVdKaVW2UKmrVEUTcMn2eD/FkelDWehnUgRz/gZgOcLrJyCaeySHEfzuqw CT8fFvtLa8LPjOkIII24ybxT6T+ExNlls+pLIB6QmCOGInD2t04IDlTTBTmsb/VKo3QDxJ JH3EanBqcaqICo4y7iASNVAfeTfx923IGqpPY+55tsNUy4Dy9L+xeBnpl61plg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1682076057; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=/dmTtKxh+32wk6M9WG+icsY+Eq0LLEQ5KVSmyLnKoUE=; b=A4yLiKPNiWaKmKgC3M5gaoZIzjSEYrDEjatZSg0Szygm3v+GZKVoskd1ibUVfSDBAL6wcv Yj3aNpXlcYQdlzqfB8Tb3+v3BiDGzYaU5K2tzQtVTbtnx4OT2b0N6katvy5lVqzWV3cv+G U3FEuScimeg/gJcybr1sERIKHYUyUIWBJw7VGuF6AHwrSPB5U/muQQ9QpEDGcIvZsftsi4 VdmJSWpRL/0DtnKLEByUxeBuZ6Yi7J+/T+oaDL4Z2Wce766k1hxJtExf/4qOdwOaLljEJv KdvFndKG0SXZ1NsOnlh4+e21jxByBr9C2L5nk7DhMqgLC33nm/zNXhH9osYzeA== ARC-Authentication-Results: i=1; rspamd-7f66b7b68c-7mggl; auth=pass smtp.auth=dreamhost smtp.mailfrom=siddhesh@gotplt.org X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|siddhesh@gotplt.org X-MailChannels-Auth-Id: dreamhost X-Stop-Cellar: 56b17b2a1f83c402_1682076058122_4183720645 X-MC-Loop-Signature: 1682076058121:3346071840 X-MC-Ingress-Time: 1682076058121 Received: from pdx1-sub0-mail-a305.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.103.24.65 (trex/6.7.2); Fri, 21 Apr 2023 11:20:58 +0000 Received: from [192.168.0.182] (bras-vprn-toroon4834w-lp130-09-174-91-45-80.dsl.bell.ca [174.91.45.80]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: siddhesh@gotplt.org) by pdx1-sub0-mail-a305.dreamhost.com (Postfix) with ESMTPSA id 4Q2sXT1W4Vz59; Fri, 21 Apr 2023 04:20:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gotplt.org; s=dreamhost; t=1682076057; bh=/dmTtKxh+32wk6M9WG+icsY+Eq0LLEQ5KVSmyLnKoUE=; h=Date:Subject:To:Cc:From:Content-Type:Content-Transfer-Encoding; b=alHYE8RqDcjISo6dSizmu7mHldeIiHx54IpWi3oX9uZ5Nt+l8wLPBKPo9VsdU9R8j tbckR01sMVJcrBwJsDNuuuKvMi1JeOljN6+/JqUVNiROHwFpuZ2Gy+TrA4q4KjswQp VjhpF3tG9CgoxgAa/rA6J+tnKa8/2DQDot5FfshxTqvBEKR9+W1NZet035T2rqF2DO S0zvkG/Fe1GzXUdX2CWMz8ybdCZdAskjeixobTSUTOEaUUaa7YEwNT2Me2jbZ5vfMb miAK812n4YJcokEK/PsEnZB3tVSunCCUYsjAd7lz4Q5CUOzbaMnUrFlCJ2kPrKu0gY 3rnyfhz2eOhCw== Message-ID: <95070070-8b98-0171-7027-0c29c0efa58f@gotplt.org> Date: Fri, 21 Apr 2023 07:20:56 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: [PATCH] Implement range-op entry for sin/cos. Content-Language: en-US To: Jakub Jelinek Cc: Aldy Hernandez , "Joseph S. Myers" , GCC patches , Andrew MacLeod References: <20230418131250.310916-1-aldyh@redhat.com> <64abfdef-8eae-9ce9-af62-c57c14c9ffbb@gotplt.org> From: Siddhesh Poyarekar In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3032.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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 2023-04-21 02:52, Jakub Jelinek wrote: > On Thu, Apr 20, 2023 at 09:14:10PM -0400, Siddhesh Poyarekar wrote: >> On 2023-04-20 13:57, Siddhesh Poyarekar wrote: >>> For bounds that aren't representable, one could get error bounds from >>> libm-test-ulps data in glibc, although I reckon those won't be >>> exhaustive.  From a quick peek at the sin/cos data, the arc target seems >>> to be among the worst performers at about 7ulps, although if you include >>> the complex routines we get close to 13 ulps.  The very worst >>> imprecision among all math routines (that's gamma) is at 16 ulps for >>> power in glibc tests, so maybe allowing about 25-30 ulps error in bounds >>> might work across the board. >> >> I was thinking about this a bit more and it seems like limiting ranges to >> targets that can generate sane results (i.e. error bounds within, say, 5-6 >> ulps) and for the rest, avoid emitting the ranges altogether. Emitting a bad >> range for all architectures seems like a net worse solution again. > > Well, at least for basic arithmetics when libm functions aren't involved, > there is no point in disabling ranges altogether. Oh yeah, I did mean only franges for math function call results. > And, for libm functions, my plan was to introduce a target hook, which > would have combined_fn argument to tell which function is queried, > machine_mode to say which floating point format and perhaps a bool whether > it is ulps for these basic math boundaries or results somewhere in between, > and would return in unsigned int ulps, 0 for 0.5ulps precision. > So, we could say for CASE_CFN_SIN: CASE_CFN_COS: in the glibc handler > say that ulps is say 3 inside of the ranges and 0 on the boundaries if > !flag_rounding_math and 6 and 2 with flag_rounding_math or whatever. > And in the generic code don't assume anything if ulps is say 100 or more. > The hooks would need to be a union of precision of supported versions of > the library through the history, including say libmvec because function > calls could be vectorized. > And default could be that infinite precision. > Back in November I've posted a proglet that can generate some ulps from > random number testing, plus on glibc we could pick maximums from ulps files. > And if needed, say powerpc*-linux could override the generic glibc > version for some subset of functions and call default otherwise (say at > least for __ibm128). Ack, that sounds like a plan. Thanks, Sid