From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 78990 invoked by alias); 14 Aug 2019 14:16:24 -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 78915 invoked by uid 89); 14 Aug 2019 14:16:15 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=play, HContent-Transfer-Encoding:8bit X-HELO: mail-wm1-f50.google.com Received: from mail-wm1-f50.google.com (HELO mail-wm1-f50.google.com) (209.85.128.50) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 14 Aug 2019 14:16:14 +0000 Received: by mail-wm1-f50.google.com with SMTP id m125so4614749wmm.3 for ; Wed, 14 Aug 2019 07:16:13 -0700 (PDT) Return-Path: Received: from abulafia.quesejoda.com (185.red-79-157-157.dynamicip.rima-tde.net. [79.157.157.185]) by smtp.gmail.com with ESMTPSA id g2sm7064906wru.27.2019.08.14.07.16.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Aug 2019 07:16:09 -0700 (PDT) Subject: Re: types for VR_VARYING To: Andrew MacLeod , Jeff Law , gcc-patches References: <7719cab1-5e3a-be7a-0260-d89add495c3e@redhat.com> <9586e8af-4552-9535-5bcd-a754fa1d7ccd@redhat.com> From: Aldy Hernandez Message-ID: Date: Wed, 14 Aug 2019 14:39:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2019-08/txt/msg00986.txt.bz2 On 8/14/19 9:50 AM, Andrew MacLeod wrote: > On 8/13/19 8:39 PM, Aldy Hernandez wrote: >> >> >> Yes, it was 2X. >> >> I noticed that Richi made some changes to the lattice handling for >> VARYING while the discussion was on-going.  I missed these, and had >> failed to adapt the patch for it.  I would appreciate a final review >> of the attached patch, especially the vr-values.c changes, which I >> have modified to play nice with current trunk. >> >> I also noticed that Andrew's patch was setting num_vr_values to >> num_ssa_names + num_ssa_names / 10.  I think he meant num_vr_values + >> num_vr_values / 10.  Please verify the current incantation makes sense. >> > no, I meant num_ssa_names.  We are resizing the vector because > num_vr_values is out of date (and smaller than num_ssa_names is now), so > we need to resize the vector to be at least the number of ssa-names... > and I added 10% just in case we arent done adding new ones. > > > if num_vr_values is 100, and we've added 200 ssa-names, num_ssa_names > would now be 300.   if you resize based on num_vr_values, you could > still go off the end of the vector. OK, I've changed the resize to allocate 2X as well. So now we'll have: + unsigned int old_sz = num_vr_values; + num_vr_values = num_ssa_names * 2; + vr_value = XRESIZEVEC (value_range *, vr_value, num_vr_values); etc And the original allocation will also be 2X. Aldy