From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13123 invoked by alias); 11 Dec 2003 19:38:21 -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 13116 invoked from network); 11 Dec 2003 19:38:20 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 11 Dec 2003 19:38:20 -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 hBBJcJ226365; Thu, 11 Dec 2003 14:38:19 -0500 Received: from speedy.slc.redhat.com (vpn50-10.rdu.redhat.com [172.16.50.10]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id hBBJcI210761; Thu, 11 Dec 2003 14:38:18 -0500 Received: from redhat.com (law@localhost) by speedy.slc.redhat.com (8.12.10/8.12.8/Submit) with ESMTP id hBBJcE3T024871; Thu, 11 Dec 2003 12:38:15 -0700 Message-Id: <200312111938.hBBJcE3T024871@speedy.slc.redhat.com> X-Authentication-Warning: speedy.slc.redhat.com: law owned process doing -bs To: Zdenek Dvorak cc: Diego Novillo , "gcc@gcc.gnu.org" Reply-To: law@redhat.com Subject: Re: [tree-ssa] Lazy updating of stmt operands In-Reply-To: Your message of "Sun, 07 Dec 2003 18:46:22 +0100." <20031207174622.GA13528@atrey.karlin.mff.cuni.cz> From: law@redhat.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 11 Dec 2003 19:39:00 -0000 X-SW-Source: 2003-12/txt/msg00671.txt.bz2 In message <20031207174622.GA13528@atrey.karlin.mff.cuni.cz>, Zdenek Dvorak wri tes: >1) Merge_blocks. The natural way (for virtual operands, the only way) of > getting rid of the degenerated phi nodes in the second block is to copy > propagate the set implied by the phi node. Since cfg cleanup should > be fast, I don't like scanning of all statements as implied by > compute_immediate_uses. Before spending a lot of time worrying about this, I would first look into why the combination of the dominator optimizer and DCE doesn't kill such PHI nodes. While I'd like to have some generic code to optimize away useless PHIs, in practice I've haven't found the need. jeff