From patchwork Wed Jul 20 02:16:03 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kugan Vivekanandarajah X-Patchwork-Id: 650527 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 3rvLBc3hk3z9stY for ; Wed, 20 Jul 2016 12:16:38 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b=TvGDj9KR; 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:from :subject:to:cc:message-id:date:mime-version:content-type; q=dns; s=default; b=hCzP2zennp3gjfa0bvQOqXEXpdvH3Owkz2PVJn2NNqcJWBZyR8 j0omEWYB6QKOYzniaJF3Y2+aTTa+B5936+Ii8qvUiMxap/yaHNwYwOwQyakWm8HO CWi5Hkm6tgKDaCZaWEiGMyr4xO0ZOfzQjH07l/DBScaY8egD0GcswfzJ8= 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:from :subject:to:cc:message-id:date:mime-version:content-type; s= default; bh=wlPlHfMG/hbV5GDieBwv3fNt8Ow=; b=TvGDj9KR0/BrMpELXjWc 1LsLRVpx/lg5IOWks25Eh6evCcD5L8u7nS9zQ+CU+NYO0WKpS6+FBShfX5htj8FM RpuDx1xnq31T3ZH8YlKccYhMVKsR2RPwcwpOu+i+4WCGo4zSBAxa2MABl7Yg9TCC aUVsWwh5sDVbsjJ8tF50lbk= Received: (qmail 91828 invoked by alias); 20 Jul 2016 02:16:27 -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 91815 invoked by uid 89); 20 Jul 2016 02:16:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_LOW, SPF_PASS autolearn=ham version=3.3.2 spammy=2016-07-20, 58, 7, 20160720 X-HELO: mail-pa0-f44.google.com Received: from mail-pa0-f44.google.com (HELO mail-pa0-f44.google.com) (209.85.220.44) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 20 Jul 2016 02:16:16 +0000 Received: by mail-pa0-f44.google.com with SMTP id iw10so12792361pac.2 for ; Tue, 19 Jul 2016 19:16:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:to:cc:message-id:date:user-agent :mime-version; bh=5TYL71aGmFJ/69i8aI67ZEIZnJTEMDTZBQQf2unqebI=; b=AZaomSgIJTths6BFFrhGA6KdEzzo5pq+VnIBtGptP8zCXeoDsQ9hrzf7sxnlgHghJy PYrvAR6kbtXuYVelWf+Ao5rWlY/Rx6PUhqWVs/dyp5wbtdYl9oKO6e0YHBqg2d+7hwRl yOkN5215TfOJORqp1jVfWS+HXB5Jt4N5rx46hmNsKgT0unuisihP33fTIl5mfsx2QwJW npoe8N6giEE1wL+OfxBXZtRnGMkzVgDWzMLN/p3fXQCzWKwf/nvCdERQ3uKAIK/dJa1N VPh+Q1GnfIwnfQvmjik6jMEnTLYURuUcP93nOJJR7EcUFW7uHKg2NzgfyMsobtINX9Y1 0yvA== X-Gm-Message-State: ALyK8tLFMwFHfEqe9Tqe0FYmGmc90RtFJVxBOq3svYyR9GcS8ULqPXl5Z4ZP1zILrZy/aFGM X-Received: by 10.66.183.80 with SMTP id ek16mr70893106pac.21.1468980974808; Tue, 19 Jul 2016 19:16:14 -0700 (PDT) Received: from [10.1.1.19] (58-6-183-210.dyn.iinet.net.au. [58.6.183.210]) by smtp.gmail.com with ESMTPSA id f10sm268482pfc.79.2016.07.19.19.16.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Jul 2016 19:16:14 -0700 (PDT) From: kugan Subject: [VRP] Use alloc-pool and obstack for value_range and vr->equiv allocations To: "gcc-patches@gcc.gnu.org" Cc: Richard Biener Message-ID: <6f6dde3f-6009-4571-58b5-a9eeadbe0451@linaro.org> Date: Wed, 20 Jul 2016 12:16:03 +1000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 X-IsSubscribed: yes Hi Richard, As discussed in IPA-VRP discussion, this patch makes tree-vrp allocations use alloc-pool and obstack for value_range and vr->equiv respectively. Other allocations are rare and left as it is. Bootstrapped and regression tested on x86-64-linux with no new regressions. Is this OK for trunk. Thanks, Kugan gcc/ChangeLog: 2016-07-20 Kugan Vivekanandarajah * tree-vrp.c (set_value_range): Use vrp_equiv_obstack with BITMAP_ALLOC. (add_equivalence): Likewise. (get_value_range): Allocate value range with vrp_value_range_pool. (vrp_initialize): Initialize vrp_equiv_obstack for equiv allocation. (vrp_finalize): Relase vrp_equiv_obstack and vrp_value_range_pool. diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c index 68f2e90..0f7bdf7 100644 --- a/gcc/tree-vrp.c +++ b/gcc/tree-vrp.c @@ -58,6 +58,7 @@ along with GCC; see the file COPYING3. If not see #include "omp-low.h" #include "target.h" #include "case-cfn-macros.h" +#include "alloc-pool.h" /* Range of values that can be associated with an SSA_NAME after VRP has executed. */ @@ -87,6 +88,10 @@ struct value_range #define VR_INITIALIZER { VR_UNDEFINED, NULL_TREE, NULL_TREE, NULL } +/* Allocation pools for tree-vrp allocations. */ +static object_allocator vrp_value_range_pool ("Tree VRP value ranges"); +static bitmap_obstack vrp_equiv_obstack; + /* Set of SSA names found live during the RPO traversal of the function for still active basic-blocks. */ static sbitmap *live; @@ -406,7 +411,7 @@ set_value_range (value_range *vr, enum value_range_type t, tree min, bitmaps, only do it if absolutely necessary. */ if (vr->equiv == NULL && equiv != NULL) - vr->equiv = BITMAP_ALLOC (NULL); + vr->equiv = BITMAP_ALLOC (&vrp_equiv_obstack); if (equiv != vr->equiv) { @@ -688,7 +693,8 @@ get_value_range (const_tree var) return CONST_CAST (value_range *, &vr_const_varying); /* Create a default value range. */ - vr_value[ver] = vr = XCNEW (value_range); + vr_value[ver] = vr = vrp_value_range_pool.allocate (); + memset (vr, 0, sizeof (*vr)); /* Defer allocating the equivalence set. */ vr->equiv = NULL; @@ -817,7 +823,7 @@ add_equivalence (bitmap *equiv, const_tree var) value_range *vr = vr_value[ver]; if (*equiv == NULL) - *equiv = BITMAP_ALLOC (NULL); + *equiv = BITMAP_ALLOC (&vrp_equiv_obstack); bitmap_set_bit (*equiv, ver); if (vr && vr->equiv) bitmap_ior_into (*equiv, vr->equiv); @@ -6882,6 +6888,7 @@ vrp_initialize (void) num_vr_values = num_ssa_names; vr_value = XCNEWVEC (value_range *, num_vr_values); vr_phi_edge_counts = XCNEWVEC (int, num_ssa_names); + bitmap_obstack_initialize (&vrp_equiv_obstack); FOR_EACH_BB_FN (bb, cfun) { @@ -10206,15 +10213,10 @@ vrp_finalize (bool warn_array_bounds_p) identify_jump_threads (); /* Free allocated memory. */ - for (i = 0; i < num_vr_values; i++) - if (vr_value[i]) - { - BITMAP_FREE (vr_value[i]->equiv); - free (vr_value[i]); - } - free (vr_value); free (vr_phi_edge_counts); + bitmap_obstack_release (&vrp_equiv_obstack); + vrp_value_range_pool.release (); /* So that we can distinguish between VRP data being available and not available. */