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

[Daniel Berlin <dberlin at dberlin dot org>]

On Monday, March 3, 2003, at 02:59  PM, Michael Matz wrote:

> Hi,
>
> On Mon, 3 Mar 2003, Daniel Berlin wrote:
>
> > new-regalloc-branch isn't very good compile-time wise.
> > For instance, we can't ever color in one pass anymore (it pretends
> > something has changed, even if nothing has, so the minimum number of
> > passes is 2).
>
> Oh, really?  That should obviously not happen.  Do you have a 
> testcase, so
> I can fix that?

You probably don't need a testcase, since it's obvious from looking at 
the code itself.  You just probably didn't notice when it happened 
(it's a one line problem, hard to see).

In one_pass, we have:

 else if (ra_pass == 1)
    {
      if (death_insns_max_uid < get_max_uid ())
        {
          sbitmap_free (insns_with_deaths);
          insns_with_deaths = sbitmap_alloc (get_max_uid ());
          sbitmap_ones (insns_with_deaths);
          death_insns_max_uid = get_max_uid ();
        }
      last_changed_insns = ra_modified_insns;
      detect_web_parts_to_rebuild ();
      last_changed_insns = NULL;
      something_spilled = 1;
      last_max_uid = get_max_uid ();
    }

Note that it's setting something_spilled to 1 unconditionally on the 
first pass (which automatically means we will do another pass, since we 
return something spilled as the return value of one_pass, and the 
calling code is "changed = one_pass ...").
This code isn't in the HEAD's ra.c.  IIRC, it was added by Denis on 
08-Jan-03, in revision 1.1.2.65:
1.1.2.65     (denisc   08-Jan-03):       something_spilled = 1;


Evil, no?

> Ciao,
> Michael.