From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 9BA883858D20 for ; Fri, 11 Nov 2022 10:59:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9BA883858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1668164391; 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; bh=uhA92oHFGv9R04MYHKSm6t7wb+OAxmGKzrvslg2roXY=; b=eGPhiAH31k51f+VBPYcS3Lvy/nL0BDNSYQ1moniFpmxQy9+Y1vHFU7o74/hgBXi6yY6MP8 lfmJDeAvNKGZPcuRscE9UubDzBud6X9bGUNMXmsfnhb6TJM6N4JFmJITob0vTM0GtBtzcW Ucw2tG1U8XtEmAeydJB8r9QPTO+146I= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-427-kmILAI95PBepMtDm3Vs8BA-1; Fri, 11 Nov 2022 05:59:47 -0500 X-MC-Unique: kmILAI95PBepMtDm3Vs8BA-1 Received: by mail-wm1-f70.google.com with SMTP id c10-20020a7bc84a000000b003cf81c2d3efso1662410wml.7 for ; Fri, 11 Nov 2022 02:59:47 -0800 (PST) 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=uhA92oHFGv9R04MYHKSm6t7wb+OAxmGKzrvslg2roXY=; b=n7CTyn2PiJ3lLAvW1hrxqg0rskNrhmfTBoqWXJN4MM6+Mo7Td0E4+NMLF85wSRxzNP DTwWMXVEgChn/oX5r7zz2BShZKV6tw8GGIlPBspZ4w+blPISY/NINT+mDeH5Pxd01r5S xpvJb0fL065wxegU3K1JVDb2A/l0UbW3FQELHYpLEuVLXg+Zf/oPZisOvFnP6FHBiS5E JWJRds5og0/CEwfVcEjSIokK1dLXtk99Ys64XujyRFaRbb1E+DKHUFUatDLGhu8jjM2R KDJuwG2C2vIH3VPKxnsF2WpnZ9Q6Rgo3tyexKSMJGsDBNHoWmv9dvO9jZ5bUWfkt/bu1 41Yw== X-Gm-Message-State: ANoB5pntQQN5TNF7b/Bo1+Zygk87mRlQ8hc5KHy59CR6HaVMGq1Fi5Yv eIezEHdszM1tdVtv6seZ2nOJxhSAtsP8hr/HQadZZmkmRy1Bp5rk7GkTKxkvP+ktPJdCEiGzWgr LZEvOSSEtQ22u2ikWAw== X-Received: by 2002:a05:600c:1e1e:b0:3c7:135a:2e4f with SMTP id ay30-20020a05600c1e1e00b003c7135a2e4fmr892638wmb.30.1668164386264; Fri, 11 Nov 2022 02:59:46 -0800 (PST) X-Google-Smtp-Source: AA0mqf7viXc5NFGudhHSH0LCrBEECBUAQpWUQnx8JX9DBX3drNvYN7ATva/oazJn80tJKtm76MpODQ== X-Received: by 2002:a05:600c:1e1e:b0:3c7:135a:2e4f with SMTP id ay30-20020a05600c1e1e00b003c7135a2e4fmr892622wmb.30.1668164385973; Fri, 11 Nov 2022 02:59:45 -0800 (PST) Received: from [192.168.1.2] ([139.47.33.22]) by smtp.gmail.com with ESMTPSA id bl21-20020adfe255000000b002366dd0e030sm1572414wrb.68.2022.11.11.02.59.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 11 Nov 2022 02:59:45 -0800 (PST) Message-ID: Date: Fri, 11 Nov 2022 11:59:44 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.1 Subject: Re: [PATCH] range-op: Implement floating point multiplication fold_range [PR107569] To: Jakub Jelinek Cc: gcc-patches@gcc.gnu.org References: <7304acea-b8bb-c930-546a-db6e3b3ff96b@redhat.com> <91a2e8c2-c846-6e8a-952e-d497db2fed50@redhat.com> From: Aldy Hernandez In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,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_NONE,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/11/22 11:47, Jakub Jelinek wrote: > On Fri, Nov 11, 2022 at 11:01:38AM +0100, Aldy Hernandez wrote: >>> I've tried following, but it suffers from various issues: >>> 1) we don't handle __builtin_signbit (whatever) == 0 (or != 0) as guarantee >>> that in the guarded code whatever has signbit 0 or 1 >> >> We have a range-op entry for __builtin_signbit in cfn_signbit. Is this a >> shortcoming of this code, or something else? > > Dunno, I admit I haven't investigated it much. I just saw it when putting > a breakpoint on the mult fold_range. Could you send me a small testcase. I can look into that. > >>> 2) __builtin_isinf (x) > 0 is lowered to x > DBL_MAX, but unfortunately we don't >>> infer from that [INF,INF] range, but [DBL_MAX, INF] range >>> 3) what I wrote above, I think we don't handle [0, 2] * [INF, INF] right but >>> due to 2) we can't see it >> >> Doesn't this boil down to a representation issue? I wonder if we should >> bite the bullet and tweak build_gt() and build_lt() to represent open >> ranges. In theory it should be one more/less ULP, while adjusting for >> HONOR_INFINITIES. > > At least with the exception of MODE_COMPOSITE_P, I think we don't need > to introduce open ranges (and who cares about MODE_COMPOSITE_P if it is > conservatively correct). > For other floats, I think > x > cst > is always equivalent to > x >= nextafter (cst, inf) > and > x < cst > is always equivalent to > x <= nextafter (cst, -inf) > except for the signed zero cases which needs tiny bit more thought. > So, if we have > if (x > DBL_MAX) > then in code guarded by that we can just use [INF, INF] as range. Yeah, yeah. That's exactly what I meant... using nextafter. I'll look into that, as there seems there's more than one issue related to our lack of precision in representing < and >. > >> If the signbit issue were resolved and we could represent > and < properly, >> would that allow us to write proper testcases without having to writing a >> plug-in (which I assume is a lot harder)? > > I don't know, we'd need to see. > First work out on all the issues that result on the testcase the operand > ranges aren't exactly what we want (whether on the testcase side or on the > range-ops side or wherever) and once that looks ok, see if the ranges > on the rN/sN vars are correct and if so, watch what hasn't been folded away > and why. > I think the plugin would be 100-200 lines of code and then we could just > write multiple testcases against the plugin. If you think the plug-in will get better test coverage, by all means. I was just trying to save you/us some work. Andrew, do you have any thoughts on the plug-in? Aldy