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 150273858D32 for ; Mon, 5 Sep 2022 06:27:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 150273858D32 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=1662359222; 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; bh=iJ07Jl0KLh/SNu/PTDQIxBfZ22ER/Zx1IpfK/h7Z9+k=; b=W9eSJzYxmNfN5o556eK6k3DSsww60jFpjF6AoU+4fO0Dfc0WhgzIIzMWMZQal8YjZwOy10 0OCa263COn4dHq4BvF1t6v2YvcDdBpgJrTovNJF9Qf5Rq8AItYy7CwrmBqrtSHCC5KHEyz 3DxYDptfLBagd7e2hZoZXmZ/FCTgRuk= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-325-mtQ8Aj4UNYucPk1cEUvBxQ-1; Mon, 05 Sep 2022 02:27:01 -0400 X-MC-Unique: mtQ8Aj4UNYucPk1cEUvBxQ-1 Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.rdu2.redhat.com [10.11.54.10]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 481D11C05143; Mon, 5 Sep 2022 06:27:01 +0000 (UTC) Received: from abulafia.quesejoda.com (unknown [10.39.192.210]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D43CD403167; Mon, 5 Sep 2022 06:27:00 +0000 (UTC) Received: from abulafia.quesejoda.com (localhost [127.0.0.1]) by abulafia.quesejoda.com (8.17.1/8.17.1) with ESMTPS id 2856Qw4f3240747 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 5 Sep 2022 08:26:58 +0200 Received: (from aldyh@localhost) by abulafia.quesejoda.com (8.17.1/8.17.1/Submit) id 2856QvM33240746; Mon, 5 Sep 2022 08:26:57 +0200 From: Aldy Hernandez To: GCC patches Cc: Andrew MacLeod , Jakub Jelinek , Joseph Myers , Aldy Hernandez Subject: [PATCH] Fold __builtin_signbit to nonzero instead of 1. Date: Mon, 5 Sep 2022 08:26:55 +0200 Message-Id: <20220905062655.3240675-1-aldyh@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.85 on 10.11.54.10 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="US-ASCII"; x-default=true X-Spam-Status: No, score=-12.3 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_LOW,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE 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: After Joseph's comment wrt __builtin_signbit, I have been unable to convince myself that arbitrarily folding __builtin_signbit () of a negative number to 1 is correct. For example, on the true side of x < -5.0 we know the sign bit is set, but on the false side, we know nothing because X may be a NAN. I don't want to put ourselves in a position where the same call to __builtin_signbit can return two different things (1 or negative whatever), so I'm going to return nonzero which is correct across the board until someone can convince me otherwise. Setting the range to nonzero still allows us to fold conditionals checking __fold_builtin, while not actually propagating a 1. Zero propagation still works. That being said, I still think we should be folding __builtin_signbit's of negative numbers to whatever the hardware returns, instead of 1/0 like what the front ends do. I am going to push this if tests succeed. gcc/ChangeLog: * gimple-range-fold.cc (fold_using_range::range_of_builtin_int_call): Fold a set signbit in __builtin_signbit to nonzero. gcc/testsuite/ChangeLog: * gcc.dg/tree-ssa/vrp-float-signbit-2.c: New test. --- gcc/gimple-range-fold.cc | 5 +--- .../gcc.dg/tree-ssa/vrp-float-signbit-2.c | 24 +++++++++++++++++++ 2 files changed, 25 insertions(+), 4 deletions(-) create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/vrp-float-signbit-2.c diff --git a/gcc/gimple-range-fold.cc b/gcc/gimple-range-fold.cc index d8497fc9be7..3543f0980b8 100644 --- a/gcc/gimple-range-fold.cc +++ b/gcc/gimple-range-fold.cc @@ -1032,10 +1032,7 @@ fold_using_range::range_of_builtin_int_call (irange &r, gcall *call, if (tmp.get_signbit ().varying_p ()) return false; if (tmp.get_signbit ().yes_p ()) - { - tree one = build_one_cst (type); - r.set (one, one); - } + r.set_nonzero (type); else r.set_zero (type); return true; diff --git a/gcc/testsuite/gcc.dg/tree-ssa/vrp-float-signbit-2.c b/gcc/testsuite/gcc.dg/tree-ssa/vrp-float-signbit-2.c new file mode 100644 index 00000000000..954c7ebd4f8 --- /dev/null +++ b/gcc/testsuite/gcc.dg/tree-ssa/vrp-float-signbit-2.c @@ -0,0 +1,24 @@ +// { dg-do compile } +// { dg-options "-O2 -fdump-tree-evrp" } + +// Test that the only thing we know about the signbit about negative number is +// that it's not 0. + +void link_error (); + +int num; + +void func(float x) +{ + if (x < -5.0) + { + num = __builtin_signbit (x); + + // We may not know the exact signbit, but we know it's not 0. + if (!__builtin_signbit (x)) + link_error (); + } +} + +// { dg-final { scan-tree-dump-not "num = \[-0-9\];" "evrp" } } +// { dg-final { scan-tree-dump-not "link_error" "evrp" } } -- 2.37.1