On Mon, 26 Mar 2012, Razya Ladelsky wrote:

> > + 
> > +  /* if the latch contains more than the one statemnt of control 
> variable 
> > +     increment then it contains the body.  */
> > +  if (exit_1->dest == loop->latch && last_and_only_stmt (loop->latch))
> >      new_rhs = gimple_cond_rhs (cond_stmt);
> > 
> > please check what the comment suggests, thus,
> > 
> >        && last_and_only_stmt (loop->latch) == cond_stmt
> > 
> Richard,
> There's no simple way to do such a check,
> as the control variable increment stmt is explicitly created in 
> canonicalize_loop_ivs.
> What we do know is that it is put in the latch because we ask for it when 
> we call 
> canonicalize_loop_ivs from parloops.
> One way to get the control variable increment stmt is to use
> canonicalize_loop_ivs return value and look for the stmts that use it.
> Do you think I should add all this functionality to the code in order to 
> assert
> the stmt that is in the latch? or can I skip it ?

No, you do not need to do that.  I see the check is basically
verifying the latch is empty (apart from the newly inserted
IV update).

Well, looking at the code simply checking for an empty latch
(before canonicalize_loop_ivs) is not going to make the case
correct when we do _not_ have an empty latch.  That is, the whole
logic in transform_to_exit_first_loop seems to assume that either
the latch is empty or the header is empty, but this does not seem
to be verified anywhere (AFAIU)?  We copy the loop anyway but
exempt the code in the latch (well, it's not exactly clear
how gimple_duplicate_sese_tail will end up turning the loop
into while (...) style to me).

It might be that the patch is a progression, so it's ok in its
original form.


Reply via email to