This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Bug in ra-colorize.c:merge_moves?


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]