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 BA45E3858D35 for ; Fri, 11 Nov 2022 10:47:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BA45E3858D35 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=1668163660; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=GV/NCJGqVAmehCCn5IB6Aji5QoMI/gTbouw7G8rI3fo=; b=iSaA5SPEYL1yItSqHWG6ElusVCkuj2qCV3zWcYvyoPnhU7Wy3NwkIb27GX/iF9iEZvTwFf uTyEVjwPvCAZw/Pg8WfYRUjT00D8IbQbWdPhyH+8HiUODe8e9wWtRjru85iImVSlMppJFW iTIxhKJmDkHN8MoM1wvMth4zLRlWPck= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-587-IH4dxPbnNIqG9EXWC4LukQ-1; Fri, 11 Nov 2022 05:47:38 -0500 X-MC-Unique: IH4dxPbnNIqG9EXWC4LukQ-1 Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.rdu2.redhat.com [10.11.54.10]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id F3C2138041D1 for ; Fri, 11 Nov 2022 10:47:37 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.38]) by smtp.corp.redhat.com (Postfix) with ESMTPS id AF98E492B0A; Fri, 11 Nov 2022 10:47:37 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 2ABAlZCb3250188 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 11 Nov 2022 11:47:35 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 2ABAlYxm3250187; Fri, 11 Nov 2022 11:47:34 +0100 Date: Fri, 11 Nov 2022 11:47:34 +0100 From: Jakub Jelinek To: Aldy Hernandez Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH] range-op: Implement floating point multiplication fold_range [PR107569] Message-ID: Reply-To: Jakub Jelinek References: <7304acea-b8bb-c930-546a-db6e3b3ff96b@redhat.com> <91a2e8c2-c846-6e8a-952e-d497db2fed50@redhat.com> MIME-Version: 1.0 In-Reply-To: <91a2e8c2-c846-6e8a-952e-d497db2fed50@redhat.com> X-Scanned-By: MIMEDefang 3.1 on 10.11.54.10 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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 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. > > 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. > 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. Jakub