From patchwork Mon Oct 9 17:10:35 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Andrew MacLeod X-Patchwork-Id: 1845412 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@legolas.ozlabs.org Authentication-Results: legolas.ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=FMRLeI6U; dkim-atps=neutral Authentication-Results: legolas.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org (client-ip=8.43.85.97; helo=server2.sourceware.org; envelope-from=gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=patchwork.ozlabs.org) Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1) server-digest SHA384) (No client certificate requested) by legolas.ozlabs.org (Postfix) with ESMTPS id 4S45Cn6SGxz1yq1 for ; Tue, 10 Oct 2023 04:11:17 +1100 (AEDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id E29DF385C41F for ; Mon, 9 Oct 2023 17:11:15 +0000 (GMT) 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.133.124]) by sourceware.org (Postfix) with ESMTPS id CB68C3856DF4 for ; Mon, 9 Oct 2023 17:10:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org CB68C3856DF4 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=1696871443; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=V6OLipnYvSDela2dzEktXhyKsBQcoRgmXusB7KBmW40=; b=FMRLeI6UeQCuOFoM9wMh7ZWpCAH0mfj+XZVYDz59QnUKgt3eMvHvTiIsA5emt/fX/TPaTA mUIz1t1v0XNddH3HBf5gne2/uCUjJn9BX+MVR4dDvJaiYsRO4mIQFY1Cn8TzLCDN9yjvbF LBsv0cLW3ROeo0/5A7oflFu45F82Uto= Received: from mail-qt1-f197.google.com (mail-qt1-f197.google.com [209.85.160.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-490-eyD_xW-tPUKpp9x-5YaQuw-1; Mon, 09 Oct 2023 13:10:37 -0400 X-MC-Unique: eyD_xW-tPUKpp9x-5YaQuw-1 Received: by mail-qt1-f197.google.com with SMTP id d75a77b69052e-41957273209so42744861cf.3 for ; Mon, 09 Oct 2023 10:10:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696871432; x=1697476232; 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=7vzNC+v2lQlMqdtSKYFnjiVB2FNyy6ZW6Wo1D0v8Y4w=; b=eJTyXCRqqCpz4C1RB/P7U3P2zSuFEgOlfsd+4It7CGc3a3EyVRTCOckQ2bivnB7J37 LqR6qygeCJcDrR5UG/hWrdFAvA8VFtqHHQPpbyqlQQZtHtT9WQGalwwj1bFUw7cZeLyL Z3Vzbc1wqB15tQ/VwmhSgf3vwynJ/VW1ebp+Q+7WgsvH5Ch20VuQ6o56/1IOVggQTKpl 5HVURUbraXb2PH4PZXtE8h8klHjBwmn/L4GhHKqdYkmtNvwSUnOYak51wifD+0ve6fA/ zBmcAStd5XnXWMJCUjXATAAQcCkmESjQX67ESCSEt3FO6YemmnDQHYmdV+B7wBi6k16J UrtA== X-Gm-Message-State: AOJu0YxIdZbuOD57dPg3hJgfLd1EmAzfAv+3KVbGN0XnxlgaQK3mWv7+ 8R3PdMYxg/66Y5/In9NFndxThYWpSEYFPUj3dV7b28V5rwu+UB3Xtto7UXuJ3qQ+oQz1/pACAN8 H4c9INwVXCiySmwzG+rP9cmJOx+BJcjjev4X2qzvh64pPM9mFJKi5SxwjgNc7WVPdrYx8zvWG5v tg7A== X-Received: by 2002:a05:622a:1211:b0:418:7ec:7570 with SMTP id y17-20020a05622a121100b0041807ec7570mr16797409qtx.64.1696871432646; Mon, 09 Oct 2023 10:10:32 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFg7RvbSDUDVtRGVfg2EQx3V1A31rg4gcqAdXDIvB+4Y7l3vaVw5lhLluvPwPSxvs43GuuAOg== X-Received: by 2002:a05:622a:1211:b0:418:7ec:7570 with SMTP id y17-20020a05622a121100b0041807ec7570mr16797390qtx.64.1696871432300; Mon, 09 Oct 2023 10:10:32 -0700 (PDT) Received: from [192.168.0.174] ([104.219.124.252]) by smtp.gmail.com with ESMTPSA id fe5-20020a05622a4d4500b004166ab2e509sm3797597qtb.92.2023.10.09.10.10.31 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Oct 2023 10:10:31 -0700 (PDT) Message-ID: <21d344bf-fb9f-1f0a-31ba-27626e12562a@redhat.com> Date: Mon, 9 Oct 2023 13:10:35 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 To: gcc-patches From: Andrew MacLeod Subject: [COMMITTED] PR tree-optimization/111694 - Ensure float equivalences include + and - zero. X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US X-Spam-Status: No, score=-11.8 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_H3, 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 X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org When ranger propagates ranges in the on-entry cache, it also check for equivalences and incorporates the equivalence into the range for a name if it is known. With floating point values, the equivalence that is generated by comparison must also take into account that if the equivalence contains zero, both positive and negative zeros could be in the range. This PR demonstrates that once we establish an equivalence, even though we know one value may only have a positive zero, the equivalence may have been formed earlier and included a negative zero  This patch pessimistically assumes that if the equivalence contains zero, we should include both + and - 0 in the equivalence that we utilize. I audited the other places, and found no other place where this issue might arise.  Cache propagation is the only place where we augment the range with random equivalences. Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed. Andrew From b0892b1fc637fadf14d7016858983bc5776a1e69 Mon Sep 17 00:00:00 2001 From: Andrew MacLeod Date: Mon, 9 Oct 2023 10:15:07 -0400 Subject: [PATCH 2/2] Ensure float equivalences include + and - zero. A floating point equivalence may not properly reflect both signs of zero, so be pessimsitic and ensure both signs are included. PR tree-optimization/111694 gcc/ * gimple-range-cache.cc (ranger_cache::fill_block_cache): Adjust equivalence range. * value-relation.cc (adjust_equivalence_range): New. * value-relation.h (adjust_equivalence_range): New prototype. gcc/testsuite/ * gcc.dg/pr111694.c: New. --- gcc/gimple-range-cache.cc | 3 +++ gcc/testsuite/gcc.dg/pr111694.c | 19 +++++++++++++++++++ gcc/value-relation.cc | 19 +++++++++++++++++++ gcc/value-relation.h | 3 +++ 4 files changed, 44 insertions(+) create mode 100644 gcc/testsuite/gcc.dg/pr111694.c diff --git a/gcc/gimple-range-cache.cc b/gcc/gimple-range-cache.cc index 3c819933c4e..89c0845457d 100644 --- a/gcc/gimple-range-cache.cc +++ b/gcc/gimple-range-cache.cc @@ -1470,6 +1470,9 @@ ranger_cache::fill_block_cache (tree name, basic_block bb, basic_block def_bb) { if (rel != VREL_EQ) range_cast (equiv_range, type); + else + adjust_equivalence_range (equiv_range); + if (block_result.intersect (equiv_range)) { if (DEBUG_RANGE_CACHE) diff --git a/gcc/testsuite/gcc.dg/pr111694.c b/gcc/testsuite/gcc.dg/pr111694.c new file mode 100644 index 00000000000..a70b03069dc --- /dev/null +++ b/gcc/testsuite/gcc.dg/pr111694.c @@ -0,0 +1,19 @@ +/* PR tree-optimization/111009 */ +/* { dg-do run } */ +/* { dg-options "-O2" } */ + +#define signbit(x) __builtin_signbit(x) + +static void test(double l, double r) +{ + if (l == r && (signbit(l) || signbit(r))) + ; + else + __builtin_abort(); +} + +int main() +{ + test(0.0, -0.0); +} + diff --git a/gcc/value-relation.cc b/gcc/value-relation.cc index a2ae39692a6..0326fe7cde6 100644 --- a/gcc/value-relation.cc +++ b/gcc/value-relation.cc @@ -183,6 +183,25 @@ relation_transitive (relation_kind r1, relation_kind r2) return relation_kind (rr_transitive_table[r1][r2]); } +// When one name is an equivalence of another, ensure the equivalence +// range is correct. Specifically for floating point, a +0 is also +// equivalent to a -0 which may not be reflected. See PR 111694. + +void +adjust_equivalence_range (vrange &range) +{ + if (range.undefined_p () || !is_a (range)) + return; + + frange fr = as_a (range); + // If range includes 0 make sure both signs of zero are included. + if (fr.contains_p (dconst0) || fr.contains_p (dconstm0)) + { + frange zeros (range.type (), dconstm0, dconst0); + range.union_ (zeros); + } + } + // This vector maps a relation to the equivalent tree code. static const tree_code relation_to_code [VREL_LAST] = { diff --git a/gcc/value-relation.h b/gcc/value-relation.h index be6e277421b..31d48908678 100644 --- a/gcc/value-relation.h +++ b/gcc/value-relation.h @@ -91,6 +91,9 @@ inline bool relation_equiv_p (relation_kind r) void print_relation (FILE *f, relation_kind rel); +// Adjust range as an equivalence. +void adjust_equivalence_range (vrange &range); + class relation_oracle { public: -- 2.41.0