This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Bug in ra-colorize.c:merge_moves?
- From: Denis Chertykov <denisc at overta dot ru>
- To: Daniel Berlin <dberlin at dberlin dot org>
- Cc: Denis Chertykov <denisc at overta dot ru>, Michael Matz <matz at suse dot de>, Christian Ehrhardt <ehrhardt at mathematik dot uni-ulm dot de>, <gcc at gcc dot gnu dot org>, <gcc-patches at gcc dot gnu dot org>
- Date: 07 Mar 2003 20:46:52 +0300
- Subject: Re: Bug in ra-colorize.c:merge_moves?
- References: <71DCCB96-4FF9-11D7-89C9-000393575BCC@dberlin.org>
Daniel Berlin <dberlin at dberlin dot org> writes:
> >
> > So, number of webs reduced (number of conflicts will be definitely
> > reduced) and possibility of graph colorization increased. I hope to
> > colorize full graph in next colorization phase.
> >
> > I'm agree that this method increased a count of allocator passes, but
> > this method must improve code quality.
> >
> Sure, but that's not the problem. The problem is the code quality
> increase isn't measurable.
> I couldn't measure a significant difference in spec, or other
> benchmarks (like skidmarks, for instance), on x86 or powerpc.
> No measurable difference in benchmarks + increased time in allocation
> = bad.
> I wouldn't complain so much if it increased code quality some
> measurable amount, but if it does, i can't find it.
I'm agree with you.
I have tested my patch before the following changes:
--- Fragment from Micael's mail.
Are you sure, that you don't coalesce SPILL_SLOT_P pseudos with non-spill
slots? This indeed makes the time go up fairly much without improving the
code. The change for that was only committed a few days ago, without it,
one had needed to ignore moves with any SPILL_SLOT_P pseudo involved.
-----
I need more time for analyzing. (1,2..3 days)
Denis.