> 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 <pola...@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.
This looks good on principle, but can't we do better now that we have the loop
structure? Can't we compute is_loop_header instead of may_be_loop_header and
simplify the condition under which we mark the loop for removal? Or maybe we
should call disambiguate_loops_with_multiple_latches on entry of the pass?
Richard, what would be the "modern" approach to solving the problem here?
--
Eric Botcazou
