[Bug tree-optimization/19038] [4.0 Regression] out-of ssa causing loops to have more than one BB
amacleod at redhat dot com
gcc-bugzilla@gcc.gnu.org
Wed Jan 12 13:34:00 GMT 2005
------- 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
More information about the Gcc-bugs
mailing list