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

[Daniel Berlin <dberlin at dberlin dot org>]

> 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.

If code quality was our only measure, we could do ILP based optimal 
register allocation and spilling.

> Denis.
>
> PS: Especially for Daniel ! Look to ra-rewrite.c: actual_spill
>
> -------------- fragment of ra-rewrite.c ----------------
> actual_spill (spill_p)
>      int spill_p ATTRIBUTE_UNUSED;
> {
>   int i;
>   bitmap new_deaths;
>
>   /* If we have a webs colored by an_unusable_color (ie we think that 
> they are
>      already in frame) we must put such webs to frame.  */
>   if (/* !spill_p && */ subst_to_stack_p ())
> #------^^^^^^^^^^^^^^^^  Just remove comments and you will have extra
> #                        passes only at end of allocation process.
>     /* If you uncomment the SPILL_P usage then you will have a calls to
>        assign_stack_slots only at end of allocation process.
>        See to the caller of actual_spill.  */
>     {
> -------------------------------------------------------
>
> Daniel. Try to remove comments around `!spill_p &&' and compare 
> generated code
> quality for both cases (commented and not commented `!spill_p &&').
I tried this once, actually, about a week ago, and it caused bootstrap 
failures.


--Dan