Your proposed change to loop.c

Joern Rennecke amylaar@cygnus.co.uk
Thu Aug 12 11:40:00 GMT 1999


>   In message < 199908041742.SAA13347@phal.cygnus.co.uk >you write:
>   > > ie, precisely why is it necessary to replace find_live_and and find_giv_u
>   > ses.
>   > 
>   > I am talking about replacing find_life_end *with* find_giv_uses, and
>   > it is to increase the rebustness of the compiler and the quality of the
>   > generated code.
> I already know this.  What I am looking for is a *technical* explanation of
> the problem.
> 
> ie, describe in detail why find_life_end is broken.  Pretend that I think
> find_life_end is perfectly fine and explain to me why it is not fine.
> 
>   > The fixing of the ix field setting led to infinite loops because it
>   > aggravated hte bug with the later index handling.  These two changes
>   > must be really done at the same time.
> Ok.  So, explain the "bug with the later index handling".
> 
> You're still not providing me with any real useful information.

The code in the loops with v and i bivs after qsort requires that v and
stats[i] pertain to the same giv, for example:

      if (v->giv_type == DEST_ADDR)
        {
          /* Loop unrolling of an inner loop can even create new DEST_REG
             givs.  */
          rtx p;
          for (p = v->insn; INSN_UID (p) >= max_uid_for_loop; )
            p = PREV_INSN (p);
          stats[i].start_luid = stats[i].end_luid = INSN_LUID (p);
          if (p != v->insn)
            stats[i].end_luid++;
        }

However, updating v and i in lockstep doesn;t work since the qsort call has
reordered stats, hence v must be looked up in stats[i].giv_number.


More information about the Gcc-patches mailing list