From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26981 invoked by alias); 25 May 2010 10:40:13 -0000 Received: (qmail 26786 invoked by uid 48); 25 May 2010 10:39:54 -0000 Date: Tue, 25 May 2010 10:40:00 -0000 Message-ID: <20100525103954.26785.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug debug/41371] [4.5/4.6 Regression] var-tracking is slow and memory hungry In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "jakub at gcc dot gnu dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2010-05/txt/msg02830.txt.bz2 ------- Comment #28 from jakub at gcc dot gnu dot org 2010-05-25 10:39 ------- Created an attachment (id=20741) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20741&action=view) gcc46-pr41371.patch Another small optimization. At least on this testcase in 80% the s1node and s2var->var_part[0].loc_chain chains contain the same locations in the same order. So, if we avoid calling find_loc_in_1pdv in that case and only start calling it when they differ, the testcase can be speeded up slightly. With --enable-checking=release cc1plus the difference is: real 4m52.484s user 4m51.991s sys 0m0.446s to: real 3m38.218s user 3m37.641s sys 0m0.383s I'm going to bootstrap/regtest it now with additional statistics gathering on how many find_loc_in_1pdv calls it can avoid. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41371