From patchwork Sun Nov 4 21:49:08 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alexandre Oliva X-Patchwork-Id: 197097 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]) by ozlabs.org (Postfix) with SMTP id 4A8152C00F3 for ; Mon, 5 Nov 2012 08:49:30 +1100 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1352670571; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Received:Received:Received:From:To:Cc:Subject:References:Date: In-Reply-To:Message-ID:User-Agent:MIME-Version:Content-Type: Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:Sender:Delivered-To; bh=IjVbNolUoG6ohVFOwJ9R YwyLj6c=; b=JTmhwH9xZZq2LkxIPiQPJmSxxTOs1+n0lTs2gPC0FwlMMQk2rkyY 33D86eYcNhdCk03n9TuBT8Z5hQ0KYwfGmPqFpeSes3HtiNv1PhOZlym/9w3OrLp9 nKlD5XN5qnLN0uMsGqVleMTqzApZnf61MqZ1nzFaZW2sSQQvAMUIc1s= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:Received:Received:Received:Received:From:To:Cc:Subject:References:Date:In-Reply-To:Message-ID:User-Agent:MIME-Version:Content-Type:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=R5nYvvaObwhM6GKbwe5+Eok/1vWGMmO1yFrWMmJJlp1V6MueJ9P4nC9KPCbqdB FwBS6DFhQPnMxF+S3biuhRBDVUR5i1Bf/lT4I2U1s7On82ezHuia6SvbOoBdqlJS sZ7HCHY6K6Bx0EnOPhb5uAzlXH8UQdzxLrDNT8z+epO24=; Received: (qmail 8144 invoked by alias); 4 Nov 2012 21:49:26 -0000 Received: (qmail 8135 invoked by uid 22791); 4 Nov 2012 21:49:26 -0000 X-SWARE-Spam-Status: No, hits=-5.8 required=5.0 tests=AWL, BAYES_00, KHOP_RCVD_UNTRUST, KHOP_SPAMHAUS_DROP, RCVD_IN_DNSWL_HI, RCVD_IN_HOSTKARMA_W, RP_MATCHES_RCVD, SPF_HELO_PASS, TW_TM, T_TVD_MIME_NO_HEADERS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 04 Nov 2012 21:49:15 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id qA4LnEjm020776 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 4 Nov 2012 16:49:14 -0500 Received: from freie (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id qA4LnBrD015375 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 Nov 2012 16:49:13 -0500 Received: from livre.localdomain (livre-to-gw.oliva.athome.lsd.ic.unicamp.br [172.31.160.19]) by freie (8.14.5/8.14.5) with ESMTP id qA4LnAhv002514; Sun, 4 Nov 2012 19:49:10 -0200 Received: from livre.localdomain (aoliva@localhost.localdomain [127.0.0.1]) by livre.localdomain (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id qA4Ln9Gn001580; Sun, 4 Nov 2012 19:49:10 -0200 Received: (from aoliva@localhost) by livre.localdomain (8.14.3/8.14.3/Submit) id qA4Ln922001578; Sun, 4 Nov 2012 19:49:09 -0200 From: Alexandre Oliva To: Jakub Jelinek Cc: gcc-patches@gcc.gnu.org Subject: Re: [PR54693] loss of debug info in jump threading and loop ivopts References: <20121101092756.GF1891@tucnak.redhat.com> <20121103181523.GE1881@tucnak.redhat.com> Date: Sun, 04 Nov 2012 19:49:08 -0200 In-Reply-To: <20121103181523.GE1881@tucnak.redhat.com> (Jakub Jelinek's message of "Sat, 3 Nov 2012 19:15:23 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 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 On Nov 3, 2012, Jakub Jelinek wrote: > On Sat, Nov 03, 2012 at 02:11:22PM -0200, Alexandre Oliva wrote: >> I didn't try delaying the creation of the pointer set as you did, but >> I'm now thinking using a linear on-stack vector for searches up to some >> size might be even faster than creating the pointer set at the first >> var. > THat would be a nice thing as a follow-up (say up to 8 or 16 decls). Here's the patch. I couldn't measure any reliable improvement, though, using various alloc_counts, from 0 to 64. Keep the first few overridden bindings in a stack vector From: Alexandre Oliva for gcc/ChangeLog PR debug/54693 * tree-ssa-threadedge.c (propagate_threaded_block_debug_into): Use a stack vector before allocating a pointer set. --- gcc/tree-ssa-threadedge.c | 65 ++++++++++++++++++++++++++++++++++++++++++--- 1 files changed, 60 insertions(+), 5 deletions(-) diff --git a/gcc/tree-ssa-threadedge.c b/gcc/tree-ssa-threadedge.c index a9c671e..76b91b7 100644 --- a/gcc/tree-ssa-threadedge.c +++ b/gcc/tree-ssa-threadedge.c @@ -610,6 +610,10 @@ cond_arg_set_in_bb (edge e, basic_block bb) return false; } +DEF_VEC_O(tree); +DEF_VEC_ALLOC_O_STACK(tree); +#define VEC_tree_stack_alloc(alloc) VEC_stack_alloc (tree, alloc) + /* Copy debug stmts from DEST's chain of single predecessors up to SRC, so that we don't lose the bindings as PHI nodes are introduced when DEST gains new predecessors. */ @@ -625,10 +629,35 @@ propagate_threaded_block_debug_into (basic_block dest, basic_block src) gcc_checking_assert (dest != src); gimple_stmt_iterator gsi = gsi_after_labels (dest); - pointer_set_t *vars = pointer_set_create (); + int i = 0; + const int alloc_count = 16; // ?? Should this be a PARAM? + /* Estimate the number of debug vars overridden in the beginning of + DEST, to tell how many we're going to need to begin with. */ for (gimple_stmt_iterator si = gsi; - !gsi_end_p (si); gsi_next (&si)) + i * 4 <= alloc_count * 3 && !gsi_end_p (si); gsi_next (&si)) + { + gimple stmt = gsi_stmt (si); + if (!is_gimple_debug (stmt)) + break; + i++; + } + + VEC(tree, stack) *fewvars = NULL; + pointer_set_t *vars = NULL; + + /* If we're already starting with 3/4 of alloc_count, go for a + pointer_set, otherwise start with an unordered stack-allocated + VEC. */ + if (i * 4 > alloc_count * 3) + vars = pointer_set_create (); + else if (alloc_count) + fewvars = VEC_alloc (tree, stack, alloc_count); + + /* Now go through the initial debug stmts in DEST again, this time + actually inserting in VARS or FEWVARS. Don't bother checking for + duplicates in FEWVARS. */ + for (gimple_stmt_iterator si = gsi; !gsi_end_p (si); gsi_next (&si)) { gimple stmt = gsi_stmt (si); if (!is_gimple_debug (stmt)) @@ -643,7 +672,10 @@ propagate_threaded_block_debug_into (basic_block dest, basic_block src) else gcc_unreachable (); - pointer_set_insert (vars, var); + if (vars) + pointer_set_insert (vars, var); + else + VEC_quick_push (tree, fewvars, var); } basic_block bb = dest; @@ -675,8 +707,28 @@ propagate_threaded_block_debug_into (basic_block dest, basic_block src) or somesuch. Adding `&& bb == src' to the condition below will preserve all potentially relevant debug notes. */ - if (pointer_set_insert (vars, var)) + if (vars && pointer_set_insert (vars, var)) continue; + else if (!vars) + { + int i = VEC_length (tree, fewvars); + while (i--) + if (VEC_index (tree, fewvars, i) == var) + break; + if (i >= 0) + continue; + + if (VEC_length (tree, fewvars) < alloc_count) + VEC_quick_push (tree, fewvars, var); + else + { + vars = pointer_set_create (); + for (i = 0; i < alloc_count; i++) + pointer_set_insert (vars, VEC_index (tree, fewvars, i)); + VEC_free (tree, stack, fewvars); + pointer_set_insert (vars, var); + } + } stmt = gimple_copy (stmt); /* ??? Should we drop the location of the copy to denote @@ -686,7 +738,10 @@ propagate_threaded_block_debug_into (basic_block dest, basic_block src) } while (bb != src && single_pred_p (bb)); - pointer_set_destroy (vars); + if (vars) + pointer_set_destroy (vars); + else if (fewvars) + VEC_free (tree, stack, fewvars); } /* TAKEN_EDGE represents the an edge taken as a result of jump threading.