[tree-ssa]: Still a problem with insertion, this time, after

[Daniel Berlin]

On Mon, 2 Jun 2003, Andrew MacLeod wrote:

> On Sun, 2003-06-01 at 20:39, Daniel Berlin wrote:
> > Insertion after a LOOP_EXPR at the end of the bb seems not to work.
> > You end up with a BB that looks like:
> > (gdb) p debug_tree_bb (bb)
> > BLOCK       0
> > PRED:       ENTRY
> > SUCC:       1
> > PARENT:     nil
> > LOOP DEPTH: 0
> > NEXT BLOCK: 1
> > PREV BLOCK: -1
> > 23  while (1)
> > -1  pretmp.4_24 = in_9 + 1B
> >
>
>
> Ahhh. This was something that once upon a time was discussed I think.
Yes, it was.
Or rather, was implemented once.

> Once upon a time, the insert routines were going to be super smart and
> do lots of majik.
Which they did, many moons ago.

> Super smart routines were punted on because there were
> a number of ambiguities about what the client might want, and creating
> new basic blocks willy-nilly causes numberous algorithms to not work
> properly. So thats is left to the person doing the inserting to decide
> what to do, and the plan is to have the more complex routines (for which
> the prototypes only exist  :-( )
>
> /* Stmt list insertion routines.  */
>
> extern void bsi_insert_list_before      PARAMS ((block_stmt_iterator *, tree_stmt_anchor));
> extern void bsi_insert_list_after       PARAMS ((block_stmt_iterator *, tree_stmt_anchor));
> extern block_stmt_iterator bsi_insert_list_on_edge      PARAMS ((edge, tree_stmt_anchor));
>
>
> These routines were going to have the smarts to make whatever basic
> block modifications were necessary in order to insert a loop node, or an
> arbitrary sequence of stmts which resulted in flow changes.
>
> As a result of that, the current routines for inserting after and before
> stmts do not look at the stmt being inserted before/after nor the
> current one in order to create new basic block determinations. (except
> for splitting critical edges when so committed).
>
> So I'm guessing what you are doing is bsi_insert_after() the LOOP stmt,
> which is the end of a basic block. This results in an incorrectly formed
> block.  The stmt you are inserting should actually go at the beginning
> of the next block after the loop stmt

In this case, it looks like it should go at the beginning of the loop,
otherwise the loop would kinda never terminate, which would be bad.
Because the loop has an edge to it's beginning, which is where the phi
node is that is causing this insertion, the insertion technically
goes after the end of this bb, and the phi node bb.
IE it's an edge insertion, but only because of the way we form the bb's +
the IR.
It wouldn't be an edge insertion in Open64, for example.
Grrrrr.