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.133.124]) by sourceware.org (Postfix) with ESMTPS id BD9AF3858D28 for ; Mon, 28 Aug 2023 07:01:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BD9AF3858D28 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=1693206069; 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=0DlZPnsKpd5KJMKbHiZeFIwaalaFFzviI9xkKzP8yX8=; b=AS2uVc9uz+uULkxtQAB/tohUOoR/RLVBLOC/JAa3Yr0QQ9crcuNA1E4qCH8vBoyCxYyPnT gAUlcA37VrKShDyjYta/iejiH1btXmt8438TWiHvEhyGmU6UlP0DPz3Zu2wgwNGgp33+G/ XtmEVmwAxvUBnPOltGb86E9oOqszsR0= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-452-hD-c4w2bNBy2abm89SI9AQ-1; Mon, 28 Aug 2023 03:01:05 -0400 X-MC-Unique: hD-c4w2bNBy2abm89SI9AQ-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 3BE201035AED for ; Mon, 28 Aug 2023 07:01:02 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.45.224.16]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 011092026D76; Mon, 28 Aug 2023 07:01:01 +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 37S710pX3082065 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 28 Aug 2023 09:01:00 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 37S710ib3082064; Mon, 28 Aug 2023 09:01:00 +0200 Date: Mon, 28 Aug 2023 09:01:00 +0200 From: Jakub Jelinek To: Aldy Hernandez Cc: GCC patches , Andrew MacLeod Subject: Re: [PATCH] [frange] Relax floating point relational folding. Message-ID: Reply-To: Jakub Jelinek References: <20230823152209.351604-1-aldyh@redhat.com> MIME-Version: 1.0 In-Reply-To: <20230823152209.351604-1-aldyh@redhat.com> X-Scanned-By: MIMEDefang 3.1 on 10.11.54.4 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.4 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_H4,RCVD_IN_MSPIKE_WL,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 Wed, Aug 23, 2023 at 05:22:00PM +0200, Aldy Hernandez via Gcc-patches wrote: > BTW, we batted some ideas on how to get this work, and it seems this > is the cleaner route with the special cases nestled in the operators > themselves. Another idea is to add unordered relations, but that > would require bloating the various tables adding spots for VREL_UNEQ, > VREL_UNLT, etc, plus adding relations for VREL_UNORDERED so the > intersects work correctly. I'm not wed to either one, and we can > certainly revisit this if it becomes burdensome to maintain (or to get > right). My strong preference would be to have the full set of operations, i.e. VREL_LTGT, VREL_{,UN}ORDERED, VREL_UN{LT,LE,GT,GE,EQ}, then everything will fall out of this cleanly, not just some common special cases, but also unions of them, intersections etc. The only important question is if you want to differentiate VREL_* for floating point comparisions with possible NANs vs. other comparisons in the callers, then one needs effectively e.g. 2 sets of rr_* tables in value-relation.cc and what exactly say VREL_EQ inverts to etc. is then dependent on the context (this is what we do at the tree level normally, e.g. fold-const.cc (invert_tree_comparison) has honor_nans argument), or whether it would be a completely new set of value relations, so even for EQ/NE etc. one would use VRELF_ or something similar. Jakub