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 5FD513858D28 for ; Wed, 25 Jan 2023 11:15:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5FD513858D28 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=1674645317; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=LcIuYYdPWvV4EoJOr9NuFSKcxY2TxDLA7bJkSahvo3c=; b=LaBGPSp46YoQ/lXLFCtLcMHjtusZO0rlbpgjMA+dnMlAQwHLdRPXK2eKWFABcwD9cXj7ja WogQXHi3PlIpcdUdvOnGl5Q3lDBRkJAkzuE92U7n9Xtnw86i3DWgpuBpFx+U6lyqAVMAKr XvNEVqmeUGmuBQhWDQhPrQpkrrruzEI= 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-436-C807WLWNOvyawKAps7QZPg-1; Wed, 25 Jan 2023 06:15:13 -0500 X-MC-Unique: C807WLWNOvyawKAps7QZPg-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 64C6680D180; Wed, 25 Jan 2023 11:15:13 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.223]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 1CA2E14171BB; Wed, 25 Jan 2023 11:15:12 +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 30PBFAtj2649676 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 25 Jan 2023 12:15:10 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 30PBF9Kv2649675; Wed, 25 Jan 2023 12:15:09 +0100 Date: Wed, 25 Jan 2023 12:15:09 +0100 From: Jakub Jelinek To: Andrew MacLeod Cc: gcc-patches , "hernandez, aldy" , Richard Biener Subject: Re: [PATCH 2/2] Add VREL_OTHER for FP unsupported relations. Message-ID: Reply-To: Jakub Jelinek References: <0f6b2db4-8b46-9a1f-3bcf-0ef2e9e2c3e0@redhat.com> MIME-Version: 1.0 In-Reply-To: <0f6b2db4-8b46-9a1f-3bcf-0ef2e9e2c3e0@redhat.com> X-Scanned-By: MIMEDefang 3.1 on 10.11.54.7 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.5 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 Tue, Jan 24, 2023 at 10:57:12AM -0500, Andrew MacLeod wrote: > That is the way VREL_OTHER is implemented in the table. > > So the problem is not on the true side of the IF condition as in your > example, its on the false side. We see this commonly in code like this > > > if (x <= y)     // FALSE side registers x > y >   blah() > else if (x >= y)  // FALSE side registers x < y >   blah() > else >   // Here we get VREL_UNDEFINED. In that case, I think the problem isn't in the intersection, which works correctly, but in wherever we (again, for HONOR_NANS (type) only) make the assumptions about the else branches. In the above case, the first blah has VREL_LE, that is correct, but the else of it (when the condition isn't true but is false) isn't VREL_GT, but VREL_UNGT (aka VREL_OTHER). So, for the HONOR_NANS (type) cases we need to adjust relation_negate callers. On trees, you can e.g. look at fold-const.cc (invert_tree_comparison), though that one for HONOR_NANS (type) && flag_trapping_math punts in most cases to preserve exceptions. But you can see there the !honor_nans cases where it acts like relation_negate, and then the honor_nans cases, where VREL_*: VARYING UNDEFINED LT LE GT GE EQ NE LTGT ORDERED UNORDERED UNLT UNLE UNGT UNGE UNEQ negate to UNDEFINED VARYING UNGE UNGT UNLE UNLT NE EQ UNEQ UNORDERED ORDERED GE GT LE LT LTGT Or, in the world where VREL_OTHER is a wildcard for LTGT ORDERED UNORDERED UNLT UNLE UNGT UNGE UNEQ the less useful VARYING UNDEFINED LT LE GT GE EQ NE OTHER negates to UNDEFINED VARYING OTHER OTHER OTHER OTHER NE EQ OTHER But I'm afraid the above has VREL_OTHER for too many important cases, unlike intersect where it is for none unless VREL_OTHER is involved, or just a few ones for union. So, I wonder if we just shouldn't do it properly immediately and instead of VREL_OTHER introduce those VREL_LTGT, /* Less than or greater than. */ VREL_ORDERED, /* Operands not NAN. */ VREL_UNORDERED, /* One or both operands NAN. */ VREL_UNLT, /* Unordered or less than. */ VREL_UNLE, /* Unordered or less than or equal. */ VREL_UNGT, /* Unordered or greater than. */ VREL_UNGE, /* Unordered or greater than or equal. */ VREL_UNEQ /* Unordered or equal. */ In that case, rather than using relation_{negate,union,intersect} etc. either those functions should take an argument whether it is a HONOR_NANS (type) floating point or not and use two separate tables under the hood, or have two sets of routines and choose which one to use in the callers. I think one routine with an extra argument would be cleaner though. The above would grow the tables quite a bit (though, we could for the non-FP cases limit ourselves to a subset), but because all the VREL_* constants are enumerals with small integers values and the arrays should be (but aren't for some reason?) static just make the arrays contain unsigned char and do the casts to the enum in the relation_{negate,intersect,union} etc. wrappers. Also, I think the rr_*_table arrays should be const, we don't want to change them, right? And a few other arrays too, like relation_to_code. BTW, with the above extra 8 codes we could use the ORDERED_EXPR etc. tree codes there. Jakub