From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2303 invoked by alias); 22 Aug 2011 11:54:22 -0000 Received: (qmail 2294 invoked by uid 22791); 22 Aug 2011 11:54:21 -0000 X-SWARE-Spam-Status: No, hits=-6.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS 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; Mon, 22 Aug 2011 11:54:05 +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 p7MBs5KW009641 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 22 Aug 2011 07:54:05 -0400 Received: from tyan-ft48-01.lab.bos.redhat.com (tyan-ft48-01.lab.bos.redhat.com [10.16.42.4]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p7MBs4IL018017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Aug 2011 07:54:05 -0400 Received: from tyan-ft48-01.lab.bos.redhat.com (localhost.localdomain [127.0.0.1]) by tyan-ft48-01.lab.bos.redhat.com (8.14.4/8.14.4) with ESMTP id p7MBs4DP023413; Mon, 22 Aug 2011 13:54:04 +0200 Received: (from jakub@localhost) by tyan-ft48-01.lab.bos.redhat.com (8.14.4/8.14.4/Submit) id p7MBs3D1023411; Mon, 22 Aug 2011 13:54:03 +0200 Date: Mon, 22 Aug 2011 12:57:00 -0000 From: Jakub Jelinek To: Dimitrios Apostolou Cc: gcc-patches@gcc.gnu.org, Steven Bosscher , Alexandre Oliva Subject: Re: [var-tracking] [not-good!] disable shared_hash and other simplifications Message-ID: <20110822115403.GT2687@tyan-ft48-01.lab.bos.redhat.com> Reply-To: Jakub Jelinek References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes 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 X-SW-Source: 2011-08/txt/msg01755.txt.bz2 On Mon, Aug 22, 2011 at 02:26:58PM +0300, Dimitrios Apostolou wrote: > the attached patch applies after my previous one, and actually > cancels all runtime gains from it. It doesn't make things worse than > initially, so it's not *that* bad. You should really test it on the testcases which lead to the changes, e.g. http://gcc.gnu.org/ml/gcc-patches/2009-06/msg01586.html You might not notice significant differences on small or common testcases, but on larger testcases it may be a question whether something can be compiled at all or not. You'll see that reverting it is actually very bad for the worst cases. > * This is the part of the compiler that makes the heaviest use of > hash tables. htab_traverse(), htab_delete(), FOR_EACH_HTAB_ELEMENT > (should that be moved in libiberty?) all iterate way too many times > over hash tables. This is all because decl/value UIDs are sparse. > * Since var-tracking is happening per-function, is there a way to > produce per-function UIDs and use those in a regular array instead > of a sparse hash table? These UIDs could be produced at tree/rtx > level, and I bet other parts in the compiler could make good use of > them. That wouldn't help you, you don't want/need to represent every DECL_UID and every VALUE seen in the whole function in every bb, only those that were actually seen there. Having (number_of_seen_decl_uids+number_of_values)*number_of_basic_blocks*sizeof(void*) memory requirements would be still bigger than the size of all the hash tables together, I think much bigger actually, and also slower when you'd need to traverse it. > * From a very wide field of view, all this DF solving reminded me a > lot of what I've seen in df-*.c. Why can't variable tracking be > integrated in the main DF pass of the compiler, the one that happens > *after* register allocation? I don't think there is any significant overlap. Yes, var-tracking is a data flow algorithm, but the code that does that is just a few lines, the big part is how the merges are done and how the tracking propagates through a basic block, and that has nothing in common with df-*.c. Jakub