> Hi,
>
> > --- 316,333
> >normally. We may assume that e->dest is not a header of any loop,
> >as it now has exactly one predecessor. */
> > while (loop_outer (e->src->loop_father)
> > ! && dominated_by_p (CDI_DOMINATORS,
> > !e->src
Hi,
> --- 316,333
>normally. We may assume that e->dest is not a header of any loop,
>as it now has exactly one predecessor. */
> while (loop_outer (e->src->loop_father)
> ! && dominated_by_p (CDI_DOMINATORS,
> !e->src->loop_father->l
2012/1/4 Jan Hubicka :
>> > + l = e->src->loop_father;
>> > + while (l && loop_outer (l))
>> > + {
>> > + while (loop_outer (loop_outer (l))
>> > + && dominated_by_p (CDI_DOMINATORS,
>> > + loop_outer (l)->latch, e->dest))
>> > + unloop
> > + l = e->src->loop_father;
> > + while (l && loop_outer (l))
> > + {
> > + while (loop_outer (loop_outer (l))
> > + && dominated_by_p (CDI_DOMINATORS,
> > + loop_outer (l)->latch, e->dest))
> > + unloop (loop_outer (l), &irred_inval
On Wed, Jan 4, 2012 at 2:01 PM, Jan Hubicka wrote:
> Hi,
> in the testcase bellow the loop peeling simplifies exit condition in a way
> that the outer loop is destroyed. After some discussion with Zdenek I learnt
> that remove_path is then supposed to destroy the outer loop by calling unloop
> on
Hi,
in the testcase bellow the loop peeling simplifies exit condition in a way
that the outer loop is destroyed. After some discussion with Zdenek I learnt
that remove_path is then supposed to destroy the outer loop by calling unloop
on it, but there is thinko in the function assuming that just th
