From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21635 invoked by alias); 15 Dec 2003 21:39:17 -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 21608 invoked from network); 15 Dec 2003 21:39:16 -0000 Received: from unknown (HELO mx2.redhat.com) (66.187.237.31) by sources.redhat.com with SMTP; 15 Dec 2003 21:39:16 -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 hBFLItA00352; Mon, 15 Dec 2003 16:18:55 -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 hBFLdCP32280; Mon, 15 Dec 2003 16:39:12 -0500 Received: from p4 (vpn50-11.rdu.redhat.com [172.16.50.11]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id hBFLdBO31468; Mon, 15 Dec 2003 13:39:11 -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: <20031215210301.GB24610@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> <1071521539.31157.1824.camel@p4> <20031215210301.GB24610@atrey.karlin.mff.cuni.cz> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Mon, 15 Dec 2003 21:39:00 -0000 Message-Id: <1071524351.4055.1896.camel@p4> Mime-Version: 1.0 X-SW-Source: 2003-12/txt/msg00832.txt.bz2 On Mon, 2003-12-15 at 16:03, Zdenek Dvorak wrote: > > And how is that different than what you have to update? Oh, I see you > > are actually maintaining a double linked list for each use or def. It > > would require less memory to keep integer index that this use is in the > > defining stmt's use-list. Thats only one word instead of two for a > > prev/next pointer. > > and is quite a bit harder to manipulate (don't ask me why, just try to > think for a while how would you implement this; if you still feel it is > easy then, persuade me :-) ). Yes, it could be also done this way, but > I don't find the saving so important to make the things more complicated > than necessary. > We'll get back to this part later :-) > > > > something like > > bool immediate_uses_avail_p (tree ssa_name) > > or > > bool immediate_uses_avail_p (tree stmt) > > > > Presumably the latter, but both are easy to provide. > > ??? I don't really quite get you. Either the information should be > available for every statement or not at all. Having something in the > middle is just confusing. > I dont see why. If you want to track just a few variables, why should you pay for tracking 45,000? It'll be a lot cheaper just to track the ones you want. Thats not to say one wouldn't want all the information sometimes, but I can assure you that in CCP we dont want the info for all variables or you get more slowdown. Now, it may turn out that we get a reasonably efficient implemnation evetually it wont be an issue, but it will be an issue for the forseeable near future I think. You may find the same thing when doing loop optimizations that you only want the info for the loop you are working on. In any case, it simple enough to provide it this way now, and if it ever becomes an all-or-nothing implementation, we simply dont look at the argument to the call. Actually, come to think of it, you ought to never merge blocks if there is *any* phi node. If we do implement immediate_uses, then when we remove the PHi argument which reduces the PHI to a single argument, we will also remove the PHI at the same time using the uses info, so you will never see a PHI with a single argument if the inforamtion is available. If it isn't available, you are going to punt and not do the merge anyway. So if you see a PHI, punt. Andrew