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 BC43B3858D33 for ; Wed, 25 Jan 2023 16:12:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BC43B3858D33 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=1674663136; 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=ybd/W1kGbWufUvHUN0DgVLzCyB6MGf64tAdrUQqjfM4=; b=GUHnHpeWl1af7MAADHnTCwSYIGyDeyEhM2LnHEwtk3tgmQKHpW8PRQtn+rvtJVucyVUhCj KBEJxISC0xv4dabCgaTGQppuoGQJ9e6N6RtjBVlI7cN/vqVemmAHvdk9V6KtuN9e3PI+oF IA87tDA5mc+9Eeox/77MJnlS670okAw= Received: from mail-qk1-f198.google.com (mail-qk1-f198.google.com [209.85.222.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-609-MGduWmjoPkaer3ynKFkUXw-1; Wed, 25 Jan 2023 11:12:14 -0500 X-MC-Unique: MGduWmjoPkaer3ynKFkUXw-1 Received: by mail-qk1-f198.google.com with SMTP id y3-20020a05620a44c300b00709109448a3so11159002qkp.19 for ; Wed, 25 Jan 2023 08:12:14 -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=ybd/W1kGbWufUvHUN0DgVLzCyB6MGf64tAdrUQqjfM4=; b=BFWpKcqupw4hB39bZ0476516iggdHVhXg3SlyXMdQIQTP7CHjTooxknRrng4Onx4ly y7k/D/Wwqaa6z6JJRe6848u7kzlxvdzLgPxOdnm0dCQf86u7/wtKjgVbKPm+hz5lcL72 rRPFvGIV7LJXd6a3UJ3tIfcyzP6NKwDA2MXhl8rVYk8N2UfHjme00ydqSoLJh+MtpwZK ZA5wM5x7JaDCTp7YZC8kmj7no1Exm4PYFqb3wSUyWSRUSC+K6oegbcu8SwfOm/7iKKG6 EaxpapiL9CqzlIJVAj0CJy3ldAxK89ohut+q2xhbqZpCYC3qI8T1Rc9HwpqVOONk/iKX rncQ== X-Gm-Message-State: AFqh2kpUbUYxNTt7ulKQcfggL2Uyd8rI2o/tBwmYja9KSYSV41zEKtzX F1iN25vQtCvsJf2ZXO49g7Fto2WNsQqriDE7BxtZ4f9dAuabaoiGHbMHV8XkNZNxzBHy9q3dZj3 rBnolfsWSeCdVdHx57g== X-Received: by 2002:a05:622a:18a9:b0:3b6:9b37:e03d with SMTP id v41-20020a05622a18a900b003b69b37e03dmr40526394qtc.53.1674663134104; Wed, 25 Jan 2023 08:12:14 -0800 (PST) X-Google-Smtp-Source: AMrXdXunG7n42jdKwCta6enSCjkKA/8SYbpWf9Jqxw6+1G4ftbggdNT+zB6XStT06rNl2b1HNvoEMQ== X-Received: by 2002:a05:622a:18a9:b0:3b6:9b37:e03d with SMTP id v41-20020a05622a18a900b003b69b37e03dmr40526368qtc.53.1674663133831; Wed, 25 Jan 2023 08:12:13 -0800 (PST) Received: from ?IPV6:2607:fea8:a263:f600::fa90? ([2607:fea8:a263:f600::fa90]) by smtp.gmail.com with ESMTPSA id b23-20020ac85417000000b003b635009149sm3516553qtq.72.2023.01.25.08.12.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 25 Jan 2023 08:12:13 -0800 (PST) Message-ID: <7a3733d7-8298-7b8a-3df9-97e3340a9e3e@redhat.com> Date: Wed, 25 Jan 2023 11:12:11 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.0 Subject: Re: [PATCH 2/2] Add VREL_OTHER for FP unsupported relations. To: Jakub Jelinek Cc: gcc-patches , "hernandez, aldy" , Richard Biener References: <0f6b2db4-8b46-9a1f-3bcf-0ef2e9e2c3e0@redhat.com> <78b6c262-bc01-7b62-34ec-e4565aba96d3@redhat.com> From: Andrew MacLeod 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: 8bit X-Spam-Status: No, score=-10.8 required=5.0 tests=BAYES_00,BODY_8BITS,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,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 1/25/23 09:48, Jakub Jelinek wrote: > On Wed, Jan 25, 2023 at 09:30:44AM -0500, Andrew MacLeod wrote: >>> 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. >> Im not sure it is quite that bad.   Floating point ranges and range-ops does >> a pretty good job of tracking NANs in the ranges. They then utilize any >> available relation in addition to that. So within floating point processing, > What I meant is that when we need to (and we have to, trying to do some > weird changes in intersect doesn't really improve anything) change the > relation_negate or its callers of a relation for floating point with > possible NANs from current inversion of VREL_{LT,GT,LE,GE} which are quite > frequent to VREL_OTHER (I don't know), it can affect a lot of code. > > Now, sure, we could try to improve the situation a little bit by not > using just HONOR_NANS (type) as the decider whether we need the new 16 > cases VREL_* handling (or 8 + VREL_OTHER) or whether we can use just the 8 > cases VREL_* handling. Because, if HONOR_NANS (type) and frange can prove > that neither operand is maybe_nan and neither operand is known_nan, then > we can also use just the old 8 VREL_* codes and their relationships. > And perhaps if either operand is known_nan, then on the other side we know > it is VREL_OTHER (VREL_UNORDERED), not anything else. > Though, exactly for this I'd say it is more work and something for GCC 14. > > Proper handling of relation_negate is I'm afraid required for GCC 13. > Except we don't actually use relation_negate () anywhere...  I can delete the functions in class value_relation and value-relation.h/cc and everything compiles fine.  Its provided because I figured it would be used someday, but the range-ops handlers simply issues the appropriate relation for the LHS.. be it true or false.  they don't pick one and negate it to produce the other. I think you are missing that the VREL_* relation is not the end result used to calculate things, merely a tag that used by the range-ops handlers to assist with understanding un-obvious relations between operands on the stmt. This change is mostly for the benefit of the one place in ranger where its slightly beyond range-ops..  when we have 2 conditions feeding and logical && or ||, we look to see if there is any common ground/relation between the operands feeding the logical operation: //   c_2 = a_6 > b_7 //   c_3 = a_6 < b_7 //   c_4 = c_2 && c_3 // c_2 and c_3 can never be true at the same time, // Therefore c_4 can always resolve to false based purely on the relations. void fold_using_range::relation_fold_and_or (irange& lhs_range, gimple *s, fur_source &src) Range-ops is unable to do anything with this as it requires examining things from outside the statement, and is not easily communicated a simple relation to operator_logical_and. THIs routine proceeds to look at the defintions of c_2 and c_3, tries to determine if there are common operands, and queries for any relations between them.   If it turns out, this is something, we use intersection or fold to determine if the result of the logical operation can be folded.   THis fix is almost exclusively about that. In GCC13, I don't think there are any uses of the relation oracle outside of ranger and range-ops. So, given that, perhaps the simplest thing to do is bail on all this change, and instead simply do the following which also fixes the PR. (im running it thru tests as we speak) diff --git a/gcc/gimple-range-fold.cc b/gcc/gimple-range-fold.cc index 91eb6298254..9c5359a3fc6 100644 --- a/gcc/gimple-range-fold.cc +++ b/gcc/gimple-range-fold.cc @@ -1039,6 +1039,9 @@ fold_using_range::relation_fold_and_or (irange& lhs_range, gimple *s,    if (!ssa1_dep1 || !ssa1_dep2 || !ssa2_dep1 || !ssa2_dep2)      return; +  if (HONOR_NANS (TREE_TYPE (ssa1_dep1))) +    return; +    // Make sure they are the same dependencies, and detect the order of the    // relationship.    bool reverse_op2 = true;