This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/19038] [4.0 Regression] ivopts causing loops to have more than one BB
- From: "law at redhat dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 18 Jan 2005 05:02:51 -0000
- Subject: [Bug tree-optimization/19038] [4.0 Regression] ivopts causing loops to have more than one BB
- References: <20041216155140.19038.dje@gcc.gnu.org>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- 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