From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20336 invoked by alias); 15 Dec 2003 23:36:44 -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 20329 invoked from network); 15 Dec 2003 23:36:42 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 15 Dec 2003 23:36:42 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id hBFNaeh17770; Mon, 15 Dec 2003 18:36:40 -0500 Received: from speedy.slc.redhat.com (vpn50-19.rdu.redhat.com [172.16.50.19]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id hBFNadn26469; Mon, 15 Dec 2003 18:36:39 -0500 Received: from redhat.com (law@localhost) by speedy.slc.redhat.com (8.12.10/8.12.8/Submit) with ESMTP id hBFNaA8g019471; Mon, 15 Dec 2003 16:36:10 -0700 Message-Id: <200312152336.hBFNaA8g019471@speedy.slc.redhat.com> X-Authentication-Warning: speedy.slc.redhat.com: law owned process doing -bs To: Andrew MacLeod cc: Chris Lattner , Zdenek Dvorak , gcc mailing list Reply-To: law@redhat.com Subject: Re: [tree-ssa] Lazy updating of stmt operands In-Reply-To: Your message of "13 Dec 2003 08:45:55 EST." <1071323157.3257.138.camel@p4> From: law@redhat.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 15 Dec 2003 23:41:00 -0000 X-SW-Source: 2003-12/txt/msg00871.txt.bz2 In message <1071323157.3257.138.camel@p4>, Andrew MacLeod writes: >The Cache isnt something we're trying to work around. Thats there to >prevent us from having to muck around in trees looking for things which >are operands. The stmt is in the form of trees, our "cache" is the >equivilent of your instruction. It consists of the operands plus looking >at the tree code(s) of the stmt. > >So we have 1 word for each operand. It points to the SSA_NAME in the >stmt tree which represents that ssa version. > >As far as Im concerned, we're not working around anything. Everything >works just fine. IF someone wants/needs the def->use inforation, it can >be built today. What we dont have is the ability to keep it up to date >for some period of time, simply because we've never needed it. If the >time comes that we do need it, it is not hard to add. In fact, we could even ponder the idea of what we now know as the operand cache morphing into a lighter-weight IL at some point in the future. Jeff