From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 42864 invoked by alias); 12 Aug 2019 23:46:17 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 42856 invoked by uid 89); 12 Aug 2019 23:46:17 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,KAM_SHORT,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=wonderful X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 12 Aug 2019 23:46:15 +0000 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 7541815561 for ; Mon, 12 Aug 2019 23:46:14 +0000 (UTC) Received: from localhost.localdomain (ovpn-112-27.rdu2.redhat.com [10.10.112.27]) by smtp.corp.redhat.com (Postfix) with ESMTP id 7B90460C44; Mon, 12 Aug 2019 23:46:13 +0000 (UTC) Subject: Re: types for VR_VARYING To: Aldy Hernandez , gcc-patches Cc: Andrew MacLeod References: From: Jeff Law Openpgp: preference=signencrypt Message-ID: <7719cab1-5e3a-be7a-0260-d89add495c3e@redhat.com> Date: Tue, 13 Aug 2019 00:35:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2019-08/txt/msg00788.txt.bz2 On 8/12/19 12:43 PM, Aldy Hernandez wrote: > This is a fresh re-post of: > > https://gcc.gnu.org/ml/gcc-patches/2019-07/msg00006.html > > Andrew gave me some feedback a week ago, and I obviously don't remember > what it was because I was about to leave on PTO.  However, I do remember > I addressed his concerns before getting drunk on rum in tropical islands. FWIW found a great coffee infused rum while in Kauai last week. I'm not a coffee fan, but it was wonderful. The one bottle we brought back isn't going to last until Cauldron and I don't think I can get a special order filled before I leave :( Their more traditional rums were good as well. Koloa Rum. See if you can get it locally :-) > > This patch adds MIN/MAX values for VR_VARYING.  As was discussed > earlier, we are only changing VR_VARYING, not VR_UNDEFINED as was the > original plan. > > As I mentioned earlier, I am tired of re-doing ChangeLogs, so I'll whip > up the changelog when the review starts. ACK. > @@ -150,12 +166,11 @@ vr_values::set_defs_to_varying (gimple *stmt) > ssa_op_iter i; > tree def; > FOR_EACH_SSA_TREE_OPERAND (def, stmt, i, SSA_OP_DEF) > - { > - value_range *vr = get_value_range (def); > - /* Avoid writing to vr_const_varying get_value_range may return. */ > - if (!vr->varying_p ()) > - vr->set_varying (); > - } > + if (value_range_base::supports_type_p (TREE_TYPE (def))) > + { > + value_range *vr = get_value_range (def); > + vr->set_varying (TREE_TYPE (def)); > + } > } Is the supports_type_p stuff there to placate the calls from ipa-cp? I can live with it in the short term, but it really feels like there should be something in the ipa-cp client that avoids this silliness. > > /* Update the value range and equivalence set for variable VAR to > @@ -1920,7 +1935,7 @@ vr_values::dump_all_value_ranges (FILE *file) > vr_values::vr_values () : vrp_value_range_pool ("Tree VRP value ranges") > { > values_propagated = false; > - num_vr_values = num_ssa_names; > + num_vr_values = num_ssa_names + num_ssa_names / 10; > vr_value = XCNEWVEC (value_range *, num_vr_values); > vr_phi_edge_counts = XCNEWVEC (int, num_ssa_names); > bitmap_obstack_initialize (&vrp_equiv_obstack); My recollection was someone (Richi) proposed 2X for the initial allocation which should ensure that in all but the most pathological cases that we never trigger a reallocation. In terms of "wasted" space, it shouldn't matter in practice. So if you could check the old thread and verify that Richi recommended the 2X initial allocation and if so, make that minor update. Jeff