From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2587 invoked by alias); 18 Jan 2005 05:02:57 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 2542 invoked by alias); 18 Jan 2005 05:02:51 -0000 Date: Tue, 18 Jan 2005 05:02:00 -0000 Message-ID: <20050118050251.2540.qmail@sourceware.org> From: "law at redhat dot com" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20041216155140.19038.dje@gcc.gnu.org> References: <20041216155140.19038.dje@gcc.gnu.org> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug tree-optimization/19038] [4.0 Regression] ivopts causing loops to have more than one BB X-Bugzilla-Reason: CC X-SW-Source: 2005-01/txt/msg02353.txt.bz2 List-Id: ------- Additional Comments From law at redhat dot com 2005-01-18 05:02 ------- Subject: Re: [4.0 Regression] out-of ssa causing loops to have more than one BB On Wed, 2005-01-12 at 13:34 +0000, amacleod at redhat dot com wrote: > ------- Additional Comments From amacleod at redhat dot com 2005-01-12 13:34 ------- > So let me see, If I read this properly, this is no longer an out of ssa problem? > > notes: > - changing where we place copies based on jeffs observations in comment 25 ought > not be difficult. Good to know. Though I doubt it's really necessary. > - If we wish to change the coalesce algorithm, we should be able to simply plug > a new one in. Maybe, maybe not. The quick and dirty synopsis of Sreedhar's approach is to rewrite PHIs so that none of the args conflict with each other or the PHI result. Once that's done you coalesce the PHI args & result together, which you know is always safe. Coupled with that idea is some improvements in when/where copies are inserted (which have certain parallels to the ideas in comment #25. Contrast that to what we do, which is more like coalescing in a register allocator. If after coalescing we find that the PHI result and one or more of its arguments are in different partitions, then we insert a copy on the edge associated with the PHI argument. So the algorithms differ first in when they insert copies, where the copies are inserted and to some extent how they determine when copies are needed. [ There's another approach from the Rice team which is similar to Sreedhar, but from what I could tell does not perform particularly well. ] If I were looking for incremental improvements to our exiting out-of-ssa, I would look at bumping the cost of copies associated with backedges. Sreedhar's approach isn't really an incremental improvement -- it's more like a pre-pass for out-of-ssa which obliviates the need to do copy coalescing during out-of-ssa. jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19038