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

[Andrew MacLeod <amacleod at redhat dot com>]

On Mon, 2003-06-02 at 17:38, Daniel Berlin wrote:
> 
> 
> 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.

I dont think they were ever implemented to create basic blocks were
they?

> > 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.


Im afraid I dont see enough of the example...

The LOOP_EXPR stmt's block only has one successor in the CFG, the
LOOP_BODY... right.

So, if I get this right, your LOOP_BODY's block starts with a PHI, which
has the value coming in from the top of the loop, and the value on the
back edge. right?  

  LOOP
   |
 |-body 
 | |
 \/

So BODY starts with a PHI

BB0
   while (1)
BB1
   a_2 = PHI <a_1(0), a_2(1)>
   ...

or some such thing? 

So you want to do something with a_1 (0), so you are inserting after the
while? (LOOP_EXPR)? figuring that after the last stmt in BB0 will be
before your first stmt in BB1?

But if we implemented this a different way using branches and such, you
are still going to have issues.

If there is a conditional branch guard before entering the loop,
inserting after that stmt is still going to cause a new basic block to
be created... you really are inserting on an edge. So you cant do it
there either.  Any incoming edge may result from a goto... so you can't
blindly insert after the last stmt on the incoming edge.

I dont see what difference a COND_EXPR and LOOP_EXPR have over explicit
branches in these cases. I can make examples for and against each Im
sure where its easier one way than the other. I can argue either case, I
havent yet seen enough examples of when this is so terrible or
consistantly worse to be motivated to try to change it all. 

In your case here, because a LOOP_EXPR is always guaranteed to fall
through into the LOOP_BODY, you can insert your stmt immediately before
the LOOP_EXPR, and everything will work out for you, no new basic block.

Assuming I've guessed your example :-)

Andrew