From patchwork Wed Jun 14 16:41:52 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Aldy Hernandez X-Patchwork-Id: 775871 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3wnsqP13F3z9s5L for ; Thu, 15 Jun 2017 02:42:08 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="Y/asvYQ+"; dkim-atps=neutral DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:to:cc :from:subject:message-id:date:mime-version:content-type; q=dns; s=default; b=WAlO7t5/wT5VL/tZCL5RNl5t2UsxUw3vqEJ/7zMqBh5VXCysZ9 Du0UkUaXXTLjk/1eDoH1MqMkCwTATjP6ydWn0RpP7fex65o003i3Jn9AIIAov4fw rlf+AP4a71MJxUvymCn4AVVq6aC12Nnw7NcWXLNw+ho/WvEdeAkqIa128= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:to:cc :from:subject:message-id:date:mime-version:content-type; s= default; bh=LI9WeAlt/9g9o+4iDKTTpLs8Qr4=; b=Y/asvYQ+tDF7f/EMaUnq N5nvIyu15u9+R/k1Q9ftn9+APjgGbblDJHAJeQ4+hVKOZ9ukZ5zGeXUFy1eNXo8W DCBB4J4lQZshv6nERX/QdsWdvUPdZK+HVMyhJRWkRSzji848+SVOYPxSrvCDR84C +9icC03cIzKdztjiHkRz0TM= Received: (qmail 105398 invoked by alias); 14 Jun 2017 16:41:55 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 105385 invoked by uid 89); 14 Jun 2017 16:41:54 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-26.9 required=5.0 tests=BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=ri, H*Ad:U*aldyh X-HELO: mail-wr0-f176.google.com Received: from mail-wr0-f176.google.com (HELO mail-wr0-f176.google.com) (209.85.128.176) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 14 Jun 2017 16:41:53 +0000 Received: by mail-wr0-f176.google.com with SMTP id r103so6025057wrb.0 for ; Wed, 14 Jun 2017 09:41:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:from:subject:message-id:date:user-agent :mime-version:content-language; bh=BMy/JoQWpKW5cWRnUoEM84cEI5V5Xw41i2TQUOuSJ/0=; b=qYJwoSYY1onNIUIU7IgQ673fMZJDHbBwnWODoJkMOU3eedfZ2qmHG15bGxels4gl1r 6WxSUioeomqcnCkJfs/ytLPmfUWm8sIPDHAevBgY8uYLsEkxZ1fs7nJB2mD7PJaMiSey xUFAiLI/Pk+JG4THIMM7HgT7YPcOpC01C/5EHlg+3XzYH+IswJ/Zfsd8LY4XLblhEdoH WGvhNDw1FOjoJn3GrVIBJ1Hg2tWDcrNaK/4k2fIynCfy8zXDxeUSSdapaNc5jtrZJgMx 7xozXMtYir7hI9y/Oz5CWV6yTYQqDuV3cJMIfur3EGMW7qTorrNnpIMiJmePb0cq3g1k 3udw== X-Gm-Message-State: AKS2vOyfgunAHCUpgWZmJVZUPanJMKdA85o3XwF5rCUkTabfcWb0dnmW VhzweOpZV/1Ub7v26uQ6bg== X-Received: by 10.28.228.84 with SMTP id b81mr705657wmh.78.1497458515370; Wed, 14 Jun 2017 09:41:55 -0700 (PDT) Received: from abulafia.quesejoda.com (218.red-83-60-15.dynamicip.rima-tde.net. [83.60.15.218]) by smtp.gmail.com with ESMTPSA id t15sm580602wmd.13.2017.06.14.09.41.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Jun 2017 09:41:54 -0700 (PDT) To: Richard Biener Cc: Andrew MacLeod , gcc-patches From: Aldy Hernandez Subject: Avoid generating useless range info Message-ID: <85de74ae-9680-1461-a289-42c915b5285a@redhat.com> Date: Wed, 14 Jun 2017 12:41:52 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 Hi! As discovered in my range class work, we seem to generate a significant amount of useless range info out of VRP. Is there any reason why we can't avoid generating any range info that spans the entire domain, and yet contains nothing in the non-zero bitmask? The attached patch passes bootstrap, and the one regression it causes is because now the -Walloca-larger-than= pass is better able to determine that there is no range information at all, and the testcase is unbounded. So...win, win. OK for trunk? Aldy gcc/ * tree-vrp.c (vrp_finalize): Do not expose any useless range information. gcc/testsuite/ * gcc.dg/Walloca-14.c: Adapt test to recognize new complaint of unbounded use. diff --git a/gcc/testsuite/gcc.dg/Walloca-14.c b/gcc/testsuite/gcc.dg/Walloca-14.c index 723dbe5..f3e3f57 100644 --- a/gcc/testsuite/gcc.dg/Walloca-14.c +++ b/gcc/testsuite/gcc.dg/Walloca-14.c @@ -9,5 +9,6 @@ g (int *p) extern void f (void *); void *q = __builtin_alloca (p); /* { dg-warning "passing argument 1" } */ + /* { dg-warning "unbounded use of 'alloca'" "unbounded" { target *-*-* } 11 } */ f (q); } diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c index 716a7c2..8442b1f 100644 --- a/gcc/tree-vrp.c +++ b/gcc/tree-vrp.c @@ -10708,8 +10708,24 @@ vrp_finalize (bool warn_array_bounds_p) vr_value[i]->max) == 1))) set_ptr_nonnull (name); else if (!POINTER_TYPE_P (TREE_TYPE (name))) - set_range_info (name, vr_value[i]->type, vr_value[i]->min, - vr_value[i]->max); + { + range_info_def *ri = SSA_NAME_RANGE_INFO (name); + tree type = TREE_TYPE (name); + unsigned precision = TYPE_PRECISION (type); + /* If the range covers the entire domain and there is + nothing in the non-zero bits mask, there is no sense in + storing anything. */ + if (vr_value[i]->min == TYPE_MIN_VALUE (type) + && vr_value[i]->max == TYPE_MAX_VALUE (type) + && vr_value[i]->type == VR_RANGE + && (!ri + || ri->get_nonzero_bits () == wi::shwi (-1, precision))) + SSA_NAME_RANGE_INFO (name) = NULL; + else + set_range_info (name, vr_value[i]->type, vr_value[i]->min, + vr_value[i]->max); + } +} } substitute_and_fold (op_with_constant_singleton_value_range, vrp_fold_stmt);