From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5274 invoked by alias); 16 Dec 2003 22:49:02 -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 5262 invoked from network); 16 Dec 2003 22:49:00 -0000 Received: from unknown (HELO mx2.redhat.com) (66.187.237.31) by sources.redhat.com with SMTP; 16 Dec 2003 22:49:00 -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 hBGMSbA07702; Tue, 16 Dec 2003 17:28:37 -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 hBGMmvr00539; Tue, 16 Dec 2003 17:48:57 -0500 Received: from p4 (vpn50-42.rdu.redhat.com [172.16.50.42]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id hBGMmtO15455; Tue, 16 Dec 2003 14:48:55 -0800 Subject: Re: [tree-ssa] Lazy updating of stmt operands From: Andrew MacLeod To: Zdenek Dvorak Cc: Jeff Law , Diego Novillo , gcc mailing list In-Reply-To: <20031216222051.GA6302@atrey.karlin.mff.cuni.cz> References: <1070818186.7334.30.camel@frodo.toronto.redhat.com> <200312111936.hBBJabGj024859@speedy.slc.redhat.com> <20031211223056.GA20061@atrey.karlin.mff.cuni.cz> <1071515090.3354.1681.camel@p4> <20031215191836.GA8653@atrey.karlin.mff.cuni.cz> <1071611437.13020.198.camel@p4> <20031216222051.GA6302@atrey.karlin.mff.cuni.cz> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Wed, 17 Dec 2003 00:21:00 -0000 Message-Id: <1071614936.13039.201.camel@p4> Mime-Version: 1.0 X-SW-Source: 2003-12/txt/msg00972.txt.bz2 On Tue, 2003-12-16 at 17:20, Zdenek Dvorak wrote: > Hello, > > > > > defining stmt's annotation, so given any SSA variable, you can get to > > > > the immediate uses by looking at the annotation for SSA_NAME_DEF_STMT. > > > > It needs a marginal extention to deal with the fact that there can be > > > > multiple defs/vdefs on one stmt, but we need to do that to handle > > > > virtual defs anyway. I would prefer to keep this information right with > > > > the stmt rather than in a table on the side. > > > > > > Immediate use is not a property of the statement, but the property of > > > the ssa name; so it should be in the SSA_NAME, as my patch does, > > > not in the statement annotations. > > > > After pondering it, I have concluded you are correct, the immediate uses > > info should be attached to the SSA_NAME. The pragmatic reason is that > > it eliminates the need to have the def stmt of the SSA_NAME in place > > before the uses are seen... > > > > ie, keeping the information accurate when you are adding a new ssa_name > > would *require* you to create the DEF first, or you have no place to put > > the uses information. Although its probably good practice to issue the > > DEF first, enforcing that is pretty lame. Putting it in the SSA_NAME > > resolves ths problem since the SSA_NAME must exist in order to actually > > occur in the stmt :-). > > my reason for having the information stored in the SSA_NAME actually > was that there may be multiple definitions in a single statement, > thus making it necessary to somehow determine of which of them is used > in the statement recorded as the immediate use; this would be extremely > cumbersome. > I would have just associated it with the new operand infrastructure.. ie, you ask for the immediate uses info for a def index or vdef index, since we have that index info available easily. It was maintaining it that was the clincher for me. Andrew