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