> 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 <[email protected]>
>
> 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
