From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) by sourceware.org (Postfix) with ESMTPS id 5CDC23858D3C for ; Mon, 14 Nov 2022 14:30:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5CDC23858D3C Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pj1-x1034.google.com with SMTP id v4-20020a17090a088400b00212cb0ed97eso10768908pjc.5 for ; Mon, 14 Nov 2022 06:30:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=3njpMR3bgiQHAgDC3VhepWgrYXHQVL4Tu1+ETViwreQ=; b=hpc7GwHQZhTJo7NNI9Vyjde6VRB3UA1v2W5rIf+oLWi22mXP+b9TABVBM7poGMc3xq +RBVlVWc6cQErYlt6p7UaNzNSOiaB2tPJE9J/EnfIoyhDaS8Pm8LXRcc3o1Dwh6ztN6D a3Q97zqFZ8J3siz6Z5lnfLihXtR6cCsxt/4yKSSI0+VDhA6qpeolKYYVXy93PJYu4hdH ZDQxOEfRUb30F0icFR76w8UMKHGx2Yj99mE4hs66+IKgu3BP/S8+Ct1l5QRbTzKARbUC smueXv8fnyDWN0WItHIDyS10ukHbvGEV3fHXmRhwqaXpKTLk4vRDvhv84OV/ODtFBK++ tCKg== 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:references:cc: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=3njpMR3bgiQHAgDC3VhepWgrYXHQVL4Tu1+ETViwreQ=; b=6b3NRzVgeY8HKI7NZYdkGQQIqNpiNnokkafr6TyrLD/NWkkRrcQCH/hHSP/lUHdLbD ELyn/Gl+6m4Ym22lhs+YD8EVZOX4krHtnWc3FKHhkNdHVzMr0VKtqi1IGlDj1SM7i7/j 1sZg+te7rQhsg8s12OViABTfcaNX28mg4uy0aFaoW1fr4uXPerTXkzkcFwaAOS1kHMfB 4CjVbo53EGRjgTPWM5T4Unj8qp1up0XOEKnoTcekQ4bx9dMpD5ahUevwDxI/d/ZGObNG 4zndCpIXLMsHcHmRBS6/T0xsUCL4GvXs9Fzl09GKQicdh4KKScEzbniYZ2lKneUemOIk b3/g== X-Gm-Message-State: ANoB5pknNTShxpYyLzdk/Or8UAmdVEhwOPI0Y/pNhAq4TEgNcGKhxPv+ wCyn1YnAulLfsWVb1vb6vUY= X-Google-Smtp-Source: AA0mqf5g8lCATfx8Sk0i92xIog673D5H3T6s1iA6i1jH63UvjOSKcLL9Enw1SM2+01b9zKX/L12tFw== X-Received: by 2002:a17:902:8601:b0:186:9fc8:6688 with SMTP id f1-20020a170902860100b001869fc86688mr13755876plo.22.1668436221152; Mon, 14 Nov 2022 06:30:21 -0800 (PST) Received: from ?IPV6:2601:681:8600:13d0::f0a? ([2601:681:8600:13d0::f0a]) by smtp.gmail.com with ESMTPSA id m15-20020a656a0f000000b0045dc85c4a5fsm5966437pgu.44.2022.11.14.06.30.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Nov 2022 06:30:20 -0800 (PST) Message-ID: <6909e534-616b-035d-47fd-705a4e9fa86e@gmail.com> Date: Mon, 14 Nov 2022 07:30:18 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.1 Subject: Re: [PATCH] [range-ops] Implement sqrt. Content-Language: en-US To: Aldy Hernandez , Jakub Jelinek Cc: "Joseph S. Myers" , GCC patches , Andrew MacLeod References: <20221113200553.440728-1-aldyh@redhat.com> From: Jeff Law In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,NICE_REPLY_A,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 11/14/22 00:45, Aldy Hernandez via Gcc-patches wrote: > On Sun, Nov 13, 2022 at 9:39 PM Jakub Jelinek wrote: >> On Sun, Nov 13, 2022 at 09:05:53PM +0100, Aldy Hernandez wrote: >>> It seems SQRT is relatively straightforward, and it's something Jakub >>> wanted for this release. >>> >>> Jakub, what do you think? >>> >>> p.s. Too tired to think about op1_range. >> That would be multiplication of the same value twice, i.e. >> fop_mult with trio that has op1_op2 () == VREL_EQ? >> But see below, as sqrt won't be always precise, we need to account for >> some errors. >> >>> gcc/ChangeLog: >>> >>> * gimple-range-op.cc (class cfn_sqrt): New. >>> (gimple_range_op_handler::maybe_builtin_call): Add cases for sqrt. >> Yes, I'd like to see SQRT support in. >> The only thing I'm worried is that unlike {+,-,*,/}, negation etc. typically >> implemented in hardware or precise soft-float, sqrt is often implemented >> in library using multiple floating point arithmetic functions. And different >> implementations have different accuracy. >> >> So, I wonder if we don't need to add a target hook where targets will be >> able to provide upper bound on error for floating point functions for >> different floating point modes and some way to signal unknown accuracy/can't >> be trusted, in which case we would give up or return just the range for >> VARYING. >> Then, we could write some tests that say in a loop constructs random >> floating point values (perhaps sanitized to be non-NAN), calls libm function >> and the same mpfr one and return maximum error in ulps. >> And then record those, initially for glibc and most common targets and >> gradually maintainers could supply more. >> >> If we add an infrastructure for that within a few days, then we could start >> filling the details. One would hope that sqrt has < 10ulps accuracy if not >> already the 0.5ulp one, but for various other functions I think it can be > I don't know what would possess me to think that sqrt would be easy > ;-). Sure, I can sink a few days to flesh this out if you're willing > to review it. To Jakub's concern.  I thought sqrt was treated like +-/* WRT accuracy requirements by IEEE.   ie, for any input there is a well defined answer for a confirming IEEE implementation.   In fact, getting to that .5ulp bound is a significant amount of the  cost for a NR or Goldschmidt (or hybrid) implementation if you've got a reasonable (say 12 or 14 bit) estimator and high performance fmacs. Jeff