From patchwork Fri Mar 24 15:08:54 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Andrew MacLeod X-Patchwork-Id: 66855 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 8ABC038708F7 for ; Fri, 24 Mar 2023 15:09:39 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8ABC038708F7 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1679670579; bh=ht6aOs3CtgrOxMXarOMHOcjVPv7WSO8g5iXK4fli5hM=; h=Date:To:Subject:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=ZjH6ostQnZxzhBlibGc3e7KutbJTZmB9qxklxS3SZs2XyReLoeSaTSMBCj33G/yBT MzWVyW8y/nbh7s65VMpA/Id8qDVVdZQS6dY70RGW97OmcdIUwr/edSix7abeDwBO2Y sZdsKvl0CixRhVlzIYJHagCgONNsBq5ELSFlbF5k= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org 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 1BDB73858D35 for ; Fri, 24 Mar 2023 15:09:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1BDB73858D35 Received: from mail-qt1-f200.google.com (mail-qt1-f200.google.com [209.85.160.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-31-rRe88-4RPUKA0d1nKBl_JQ-1; Fri, 24 Mar 2023 11:09:02 -0400 X-MC-Unique: rRe88-4RPUKA0d1nKBl_JQ-1 Received: by mail-qt1-f200.google.com with SMTP id h6-20020a05622a170600b003e22c6de617so1201235qtk.13 for ; Fri, 24 Mar 2023 08:09:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679670541; h=subject:from:to:content-language:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=P7Nn0TPAfXt5/P64r6h6UHm0rsKBZPUVK3V9AjY8tj4=; b=iRoNd4GHjjbxQ2pc2k3fm+nTlF2B101BLKsgu3u8koZzpgMdeZqlT7o9y/MhaGTMLh E/0V/ZkcDjXZQ8cYVj75JWqL6CwfxnqYfCBAMqSwXo6VrweuuEC3kpPzzDcy3TlWNIaa TxSZlsMuNXjx6E9ReJI9zZUZGmLOzyN9Ldu0mx0IS6OE3E7fthl6TpXR1Qc/f04GVMrx oUMbueZMayDegLkF47W707ZVHuDQLFg4kWuCLSm+VzkmsGiSJQphfMaAk/lAT0tjcikR jZxwNQNuWdQgRmm6kNHcR+rZXaiI2dzx+v9tuGxrEKYjQWEZGkJjYlHSbgptYPugLalJ CDeA== X-Gm-Message-State: AAQBX9dWC4I8aqZhJ7hENN1QuMwNW/jzN77JiEwZQlwLjcCoApJtHrbe PWDzQl56xmtLcgCvI9eGLdbg2ZRJcOPN+OTZy1+/+nNCkfkyfgevsmgL7rPhjThsgnPl2egCOzl 0zfwtn05OGA8ppxhnCuvO61UBZSApqAftDGzckftywnWxdBZhX6TVgfU0m3Db6+Ng35b7d/nzQD +AYA== X-Received: by 2002:a05:6214:1bcb:b0:5ab:8087:91f2 with SMTP id m11-20020a0562141bcb00b005ab808791f2mr5396203qvc.7.1679670541329; Fri, 24 Mar 2023 08:09:01 -0700 (PDT) X-Google-Smtp-Source: AKy350YzGGLJh0u++qouUFsI2FLFC1DLEwcmH633UIIGIECUibYtysry/GcXoR6PJMpyYS6XrEswug== X-Received: by 2002:a05:6214:1bcb:b0:5ab:8087:91f2 with SMTP id m11-20020a0562141bcb00b005ab808791f2mr5395518qvc.7.1679670536090; Fri, 24 Mar 2023 08:08:56 -0700 (PDT) Received: from ?IPV6:2607:fea8:a263:f600::759b? ([2607:fea8:a263:f600::759b]) by smtp.gmail.com with ESMTPSA id bl28-20020a05620a1a9c00b007339c5114a9sm14388624qkb.103.2023.03.24.08.08.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 24 Mar 2023 08:08:55 -0700 (PDT) Message-ID: <2e0b9177-f8ce-d55a-d6bb-71eb89a9700d@redhat.com> Date: Fri, 24 Mar 2023 11:08:54 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 To: gcc-patches , Jakub Jelinek , Richard Biener Subject: [PATCH] PR tree-optimization/109274 - Don't interpret contents of a value_relation record. X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US X-Spam-Status: No, score=-11.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, 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 X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Patchwork-Original-From: Andrew MacLeod via Gcc-patches From: Andrew MacLeod Reply-To: Andrew MacLeod Errors-To: gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org Sender: "Gcc-patches" Before floating point relations were added, we tried to sanitize value-relation records to not include non-sensensical records... ie x != x or x < x.   Instead, we made a VREL_VARYING record with no operands. When floating point relation support was added, some of these were no longer non-sensical, AND we expanded the use of value_relation records into GORI shortly thereafter. As a result, this sanitization is no longer needed, nor desired. The Oracle does not create records with op1 == op2 already, so its only within GORI that these records can exist, and we shouldn't try to interpret them. The bug occurs because the "sanitized" records doesn't set op1 and op2, and changes the relation to VARYING..  and we expected the operands it to be set the way they were specified.  We should not be setting a VREL_VARYING record if asked to set something else.  In fact, we are missing some opportunities because we are trying to FP range-ops that op1 != op1  but its getting transformed into a VREL_VARYING record and not communicated properly. Currently bootstrapping on x86_64-pc-linux-gnu and assuming no regressions, OK for trunk? Andrew commit 1f02961b23976d35b10e2399708c6eb00632f9d6 Author: Andrew MacLeod Date: Fri Mar 24 09:18:33 2023 -0400 Don't interpret contents of a value_relation record. before floating point relations were added, we tried to sanitize value-relation records to not include non-sensensical records... ie x != x or x < x. INstead, we made a VREL_VARYING record with no operands. When floating point relations were supported, some of these were no longer non-sensical, AND we expanded the use of value_relation records into GORI. As a result, this sanitization is no longer needed. The Oracle does not create records with op1 == op2, so its only within GORI that these records can exist, and we shouldnt try to interpret them. The bug occurs because the "sanitized" records doesnt set op1 anmd op2, but we have a record so expected it to be set. PR tree-optimization/109265 PR tree-optimization/109274 gcc/ * value-relation.h (value_relation::set_relation): Always create the record that is requested. gcc/testsuite/ * gcc.dg/pr109274.c: New. diff --git a/gcc/testsuite/gcc.dg/pr109274.c b/gcc/testsuite/gcc.dg/pr109274.c new file mode 100644 index 00000000000..5dbc0232f8e --- /dev/null +++ b/gcc/testsuite/gcc.dg/pr109274.c @@ -0,0 +1,16 @@ +/* PR tree-optimization/109274 */ +/* { dg-do compile } */ +/* { dg-options "-O2 " } */ + +float a, b, c; +int d; +float bar (void); + +void +foo (void) +{ + a = 0 * -(2.0f * c); + d = a != a ? 0 : bar (); + b = c; +} + diff --git a/gcc/value-relation.h b/gcc/value-relation.h index 36a75862cc7..3177ecb1ad0 100644 --- a/gcc/value-relation.h +++ b/gcc/value-relation.h @@ -445,13 +445,6 @@ value_relation::set_relation (relation_kind r, tree n1, tree n2) { gcc_checking_assert (TREE_CODE (n1) == SSA_NAME && TREE_CODE (n2) == SSA_NAME); - if (n1 == n2 && r != VREL_EQ) - { - related = VREL_VARYING; - name1 = NULL_TREE; - name2 = NULL_TREE; - return; - } related = r; name1 = n1; name2 = n2;