From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12709 invoked by alias); 30 Aug 2004 17:01:51 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 12661 invoked from network); 30 Aug 2004 17:01:49 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 30 Aug 2004 17:01:49 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i7UH1lS0027634; Mon, 30 Aug 2004 13:01:47 -0400 Received: from [172.16.50.20] (vpn50-20.rdu.redhat.com [172.16.50.20]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i7UH1j320173; Mon, 30 Aug 2004 13:01:45 -0400 Subject: Re: GCC 3.5 Status (2004-08-29) From: Jeffrey A Law Reply-To: law@redhat.com To: Steven Bosscher Cc: Mark Mitchell , gcc@gcc.gnu.org, dberlin@dberlin.org In-Reply-To: <200408300934.13528.stevenb@suse.de> References: <4132641E.3030206@codesourcery.com> <200408300229.13652.stevenb@suse.de> <41327A88.5080903@codesourcery.com> <200408300934.13528.stevenb@suse.de> Content-Type: text/plain Organization: Red Hat, Inc Message-Id: <1093885279.2907.54.camel@localhost.localdomain> Mime-Version: 1.0 Date: Mon, 30 Aug 2004 17:46:00 -0000 Content-Transfer-Encoding: 7bit X-SW-Source: 2004-08/txt/msg01501.txt.bz2 On Mon, 2004-08-30 at 01:34, Steven Bosscher wrote: > Also, I believe the edge-vector-branch work is also purely a speedup > project - it will make looking up PHI arguments much faster. As I > have shown before on this mailing list, this is one of the major bottle > necks for passes like DOM. The edge-vector stuff is definitely a good thing. However, I would not expect a big benefit from it. Yes, there are certain codes where it would speed up DOM in a meaningful way, but in general I don't expect you'll find that it's a big improvement. I like the edge-vector work because it means we can rip out the hacks which we added to prevent the traversal of the PHI arguments from becoming a huge time sink. Speeding up DOM in the general case at this point means finding a way to stop iteration. Not surprisingly I've thought quite a bit about that problem. I haven't started any experiments, but my theory is that the cases were iterating DOM is useful can be detected by the existence of optimizable PHIs. ie, if we have a degenerate PHI such as this after DOM a1 = PHI (a0) -- or a1 = PHI (a0, a0) -- or a1 = PHI (a0, a1) Then iterating DOM may be useful. I suspect (but certainly haven't confirmed) that iterating if no such PHIs are found is relatively pointless. So we might be able to reduce iteration steps. That would be good. Again, I haven't played with this yet, so it's ripe for someone to poke around. Beyond that I've spent considerable time thinking about how to remove the iteration step completely, but it's probably not worth outlining those thoughts at the moment as they are predicated on the concept that optimizable PHIs are the key to determining what (if anything) might be gained by iterating DOM. Jeff