From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 98036 invoked by alias); 14 Aug 2019 13:50:19 -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 98027 invoked by uid 89); 14 Aug 2019 13:50:19 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=HX-Languages-Length:1087, H*M:70f4, play, HContent-Transfer-Encoding:8bit 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; Wed, 14 Aug 2019 13:50:08 +0000 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A83D4C04BD33 for ; Wed, 14 Aug 2019 13:50:07 +0000 (UTC) Received: from [10.10.120.211] (ovpn-120-211.rdu2.redhat.com [10.10.120.211]) by smtp.corp.redhat.com (Postfix) with ESMTP id BA32D34D44; Wed, 14 Aug 2019 13:50:04 +0000 (UTC) Subject: Re: types for VR_VARYING To: Aldy Hernandez , Jeff Law , gcc-patches References: <7719cab1-5e3a-be7a-0260-d89add495c3e@redhat.com> <9586e8af-4552-9535-5bcd-a754fa1d7ccd@redhat.com> From: Andrew MacLeod Message-ID: Date: Wed, 14 Aug 2019 14:16:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: <9586e8af-4552-9535-5bcd-a754fa1d7ccd@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2019-08/txt/msg00984.txt.bz2 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. Andrew