From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4675 invoked by alias); 12 Dec 2003 19:54:07 -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 3682 invoked from network); 12 Dec 2003 19:54:04 -0000 Received: from unknown (HELO mx2.redhat.com) (66.187.237.31) by sources.redhat.com with SMTP; 12 Dec 2003 19:54:04 -0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.11.6/8.11.6) with ESMTP id hBCJXlA05729; Fri, 12 Dec 2003 14:33:47 -0500 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id hBCJrvb15926; Fri, 12 Dec 2003 14:53:57 -0500 Received: from p4 (vpn50-27.rdu.redhat.com [172.16.50.27]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id hBCJrtM10031; Fri, 12 Dec 2003 11:53:55 -0800 Subject: Re: [tree-ssa] Lazy updating of stmt operands From: Andrew MacLeod To: Chris Lattner Cc: Zdenek Dvorak , Jeff Law , gcc mailing list In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 12 Dec 2003 19:55:00 -0000 Message-Id: <1071258836.14001.277.camel@p4> Mime-Version: 1.0 X-SW-Source: 2003-12/txt/msg00737.txt.bz2 On Fri, 2003-12-12 at 14:46, Chris Lattner wrote: > > > hardly; you still must scan all statements to find the uses, so I don't > > > see where you would want to get the extra efficiency. > > > > > Scanning stmts is very cheap. > > You must not have run across programs that have PHI nodes with thousands > of operands... > Yes, thats why CCP had to trim down its def->use chains to just the variables it cared about rather than all of them. It was a large memory savings to do that. > > The uses/defs are all cached. > > Don't caches take space? > Yeah, but thats already consumed. If you are suggesting we replace our entire operand implemenation with FUDs, I'm pretty sure thats not going to happen :-) So our operand cache takes up space. Adding def->use chains takes up even more space > > And if you do need it over a chain of optimizations, do it once, and > > then keep the info up to date/. You'll be a lot better off I think > > Isn't that the whole idea? > Yes, but I am suggesting we dont keep it around all the time since many optimizations do not need it, and it costs memory. The ones that do need it can build that info for the variables it cares about more efficiently. CCP cares about a different set of variables than the loop optimizer likely does. Andrew