Re: [PATCH] Don't bypass blocks with multiple latch edges (PR middle-end/54838)

[Eric Botcazou <ebotcazou@adacore.com>]

> Yikes, sorry, it wasn't clear to me what PROP_loops really does.  Anyway,
> I think I have a better fix now.  The problem is just that when removing
> BB 4 (which was a header), we have to zap ->header and ->latch.  We
> already have code for this:
> 
>   if (current_loops != NULL
>       && e->src->loop_father->latch == e->src)
>     {
>       /* ???  Now we are creating (or may create) a loop
>          with multiple entries.  Simply mark it for
>          removal.  Alternatively we could not do this
>          threading.  */
>       e->src->loop_father->header = NULL;
>       e->src->loop_father->latch = NULL;
>     }
> 
> but the thing is that when there are multiple latch edges, then
> ->latch is NULL.  So we need to keep track of how many latch edges
> the header has.  Regtested/bootstrapped on x86_64, ok for trunk?
> 
> Can I get rid of may_be_loop_header (and just use n_latch_edges > 0
> instead at that one place) in a followup?
> 
> 2012-11-29  Marek Polacek  <polacek@redhat.com>
> 
> 	PR middle-end/54838
> 	* cprop.c (bypass_block): Set header and latch to NULL when
> 	BB has more than one latch edge.
> 	(n_latches): New variable.

OK, let's tweak the patch as follows:
 1) when current_loops is not NULL, we compute may_be_loop_header and whether 
the loop has more than 1 latch edge exactly,
 2) when current_loops is NULL, we use your above method to do the same,
 3) once this is done, we return from the function before entering the loop if 
this is a (potential) header with more than 1 (potential) latch edge.  The 
comment can say that threading through a loop header with more than 1 latch 
edge is delicate and cite tree-threadupdate.c:thread_through_loop_header.

-- 
Eric Botcazou