Bad code generated by inter-block scheduling

[Jeffrey A Law]

On Wed, 2004-09-22 at 12:34, Ulrich Weigand wrote:

> 
> The task of distiguishing between interblock and speculative motion
> is done using the notion of 'potential-split-edges', as computed
> by compute_dom_prob_ps in sched-rgn.c.  As I understand this code,
> it looks for (generalized versions of) situations like this:
> 
>       [A]
>      /   \
>   [B]     [C]
> 
> If it finds such an edge A -> C, then a move from B to A would be
> speculative, else it is a regular interblock motion.
> 
> Now, in this particular case, we obviously *do* have exactly that
> situation, with [A] = bb2, [B] = bb 1, [C] = exit block.
> 
> However, the data structures available to compute_dom_prob_ps simply
> do not contain the 'bb2 -> exit' edge in the first place!  This is
> because where the private structures in sched-rgn.c are built
> (build_control_flow), all edges leading to the exit block are 
> completely ignored:
> 
>   nr_edges = 0;
>   for (i = 0; i < num_edges; i++)
>     {
>       edge e = INDEX_EDGE (edge_list, i);
> 
>       if (e->dest != EXIT_BLOCK_PTR
>           && e->src != ENTRY_BLOCK_PTR)
>         new_edge (e->src->index, e->dest->index);
>     }
> 
> >From what I see from the revision histories, the behaviour apparently
> has been the same since forever, so I don't know why this suddenly
> shows up as a problem ...
> 
> Simply adding entry/exit edges to the sched-rgn.c tables is not completely
> trivial due to the negative block index numbers; several global arrays in
> sched-rgn.c are indexed by block number.  Any suggestions how to fix this?
I've always hated the potential-split-edges nonsense in the
interblock scheduling code.  It seems to me what they're really
after is just post-dominance.

jeff