From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTP id B05F4399E06C for ; Wed, 9 Jun 2021 18:50:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B05F4399E06C Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-134-AM1WkfoIOaq6cwfQ8tteFw-1; Wed, 09 Jun 2021 14:50:45 -0400 X-MC-Unique: AM1WkfoIOaq6cwfQ8tteFw-1 Received: by mail-wm1-f71.google.com with SMTP id h9-20020a05600c3509b02901b985251fdcso1017821wmq.9 for ; Wed, 09 Jun 2021 11:50:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=5nCBrJ88qV362hCfE+qBN9z9Ch7g4qdrP9J+J1yqoGs=; b=hmv7VTI2ejVMWIBz+Dz31lJL91Er8Pcm6pSNtFLs7BpCWC6CLbsemy5zOslYRKcKIR WCmD1Y7S9FkeVL17FoOJ/PCeIvsrMAB6TcjLkumXz+c+xVR7CzgL52Hxew2r9+czgiFT ffAQ7B8DWZFAkF+xt2S5jRywSi3RyQsh/l7oBlArUxYnKCtIzRGiMep0EDvvwNjxe2Ev SAj2JrmEwx6j+qxFYzy7VTsSz90JXAH0miR9RC1SujO8Gyk2cstlXz6RE9D1ER5QigWB O5Yd4uyiddXEx1+mmXonn95H/V/a2VTSTNb/dTdDrnX6JkuDmppoVkS1DCccLwZEQoo6 bQlg== X-Gm-Message-State: AOAM533n/5SYBK44TFtjkBVpTNNX95bsTHAWWPZ5+PRhRMney8KuwFuH Nt/tk/8In1BfV1ei2mKpSgy4L7I+v+UAw8qjhcu4A0684WV/MU//wTrRqApfUVOZAjNp01Maig7 nN+qhGj9TNcZdb8iDF0UqyU5e4u91GWTlRZLBy/gVr2F2HHB9UT7vV5IBm6Etp1Bt/A== X-Received: by 2002:a7b:c8c3:: with SMTP id f3mr11159902wml.178.1623264643451; Wed, 09 Jun 2021 11:50:43 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzAFiR8eIqGs5NLLMy4FRQiEpSW7aJHwComx0N/GtKDGtSK2ic8EgmsZw1nGAH0OH6Z4Va5WA== X-Received: by 2002:a7b:c8c3:: with SMTP id f3mr11159889wml.178.1623264643170; Wed, 09 Jun 2021 11:50:43 -0700 (PDT) Received: from abulafia.quesejoda.com ([95.169.237.215]) by smtp.gmail.com with ESMTPSA id d131sm7168609wmd.4.2021.06.09.11.50.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 09 Jun 2021 11:50:42 -0700 (PDT) Subject: Re: [PATCH] Implement a context aware points-to analyzer for use in evrp. To: Martin Sebor , Richard Biener Cc: GCC patches References: <20210607101003.615929-1-aldyh@redhat.com> <49261e75-1adc-8603-4ccd-fa61fb0bde6c@redhat.com> <21ea25a3-dfc9-27cb-dfe0-537f5e27b11f@gmail.com> From: Aldy Hernandez Message-ID: Date: Wed, 9 Jun 2021 20:50:41 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <21ea25a3-dfc9-27cb-dfe0-537f5e27b11f@gmail.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-9.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, KAM_SHORT, NICE_REPLY_A, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2021 18:50:50 -0000 On 6/9/21 7:10 PM, Martin Sebor wrote: > On 6/7/21 12:29 PM, Aldy Hernandez via Gcc-patches wrote: >> > Mostly just a question of the type choices in the implementation > of the ssa_equiv_stack class: m_stack is an auto_vec while > m_replacements is a plain array.  I'd expect both to be the same > (auto_vec).  Is there a reason for this choice? > > If not, I'd suggest to use auto_vec.  That way the ssa_equiv_stack > class shouldn't need a dtor (auto_vec doesn't need to be explicitly > released before it's destroyed), though it should delete its copy > and assignment. TBH, the ssa_equiv_stack was lifted from evrp_range_analyzer (there are also 2 more copies of the same mechanism in tree-ssa-scopedtables.h). The code there already used an auto_vec, so I left that. However, for a mere array of trees, I thought it'd be simpler to use new/delete. Which in retrospect was easy to get wrong, as can be seen by: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100984 Would something like the code below work? It should also fix the PR. Thanks. Aldy diff --git a/gcc/gimple-ssa-evrp.c b/gcc/gimple-ssa-evrp.c index 7e1cf51239a..808d47506be 100644 --- a/gcc/gimple-ssa-evrp.c +++ b/gcc/gimple-ssa-evrp.c @@ -61,19 +61,18 @@ public: private: auto_vec> m_stack; - tree *m_replacements; + auto_vec m_replacements; const std::pair m_marker = std::make_pair (NULL, NULL); }; ssa_equiv_stack::ssa_equiv_stack () { - m_replacements = new tree[num_ssa_names] (); + m_replacements.safe_grow_cleared (num_ssa_names); } ssa_equiv_stack::~ssa_equiv_stack () { m_stack.release (); - delete m_replacements; } // Pushes a marker at the given point.