From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11359 invoked by alias); 12 Jan 2005 13:34:33 -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 11287 invoked by uid 48); 12 Jan 2005 13:34:26 -0000 Date: Wed, 12 Jan 2005 13:34:00 -0000 Message-ID: <20050112133426.11286.qmail@sourceware.org> From: "amacleod 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] out-of ssa causing loops to have more than one BB X-Bugzilla-Reason: CC X-SW-Source: 2005-01/txt/msg01509.txt.bz2 List-Id: ------- 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. - If we wish to change the coalesce algorithm, we should be able to simply plug a new one in. The existing one was just a quick straightforward implementation to get it working with the full intention of improving it later. Its also reasonably flexible and cost driven. tree-outof-ssa.c::coalesce_ssa_name() does all the setup work. A list of possible coalesces is created, given costs and the sorted. Coalesces are then performed by calling tree-ssa-live::coalesce_tpa_members() (tpa's are generic lists which associate trees, ie VAR trees to a partition index). The routine tree-ssa-live.c::pop_best_coalesce() deterimes the order to attempt coalesces. currently this simply retreives them in sorted ordered by "cost". cost is calculated during the building of the coalesce list via calls to tree-ssa-live.c::add_coalesce(), and is a cost value passed to the routine. The current implementation simply calls add_coalesce with a value of 1 all the time, so it ends up being simply a copy count.. ie, we try to coalesce variables which are copied between each other 4 times before we try those copied once. The original intention was to multiple each copy by 10^nest_level_of_copy, but that info wasnt easily available when I implemented it. I beleive it is now, and just haven't gotten around to doing it. It would be trivial to add that to the calls to add_coalesce. We could increase the cost again if its going to insert a copy on a latch edge quite easily. (maybe 20^nest_level instead or some such thing) Making those even more important. add_coalesce should probably be changed to avoid wraparound as well I suppose. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19038