Loop optimiser upgrade (Was RFC: BB duplication code)

[Michael Hayes]

Joern Rennecke writes:
 > > I agree that the loop notes should be weeded out.  The one useful loop
 > > note is the VTOP note that indicates if the loop exit code has been
 > > duplicated.  When this loop exists and we know that the loop body will
 > > be executed at least once if the loop header is entered.  I'm not sure
 > > of an easy means to determine this from the CFG.
 > 
 > Actually, that is the easy part.  You just have to look if the loop is
 > solely entered by fallthrough from the preceding block.  In the non-vtop
 > while loop case, you have a jump from outside to the loop exit
 > test.

Are you sure?  A simple while loop has a CFG:

    +---+
    v   |
--->H-->L
    |
    v

where H is the loop header and L is the loop latch node.

If we transform the while loop into a do-while loop and duplicate the
loop exit test we have something like:

       +---+
       v   |
-->B-->H-->L--+-->
   |          ^
   |          |
   +----------+   

where B is a node containing the duplicated exit test that is used
to bypass the loop.

My question is how do we tell this from a do-while loop with a goto
around it?

 > However, the VTOP note means more than just that the loop is executed
 > at least once when entered.  It also means that the loop exit condition
 > will be false at the start of the first iteration.  This knowledge
 > allows you to do some extra strength reduction and unroll loop
 > preconditioning transforations without emitting extra runtime checks.


I realise this thanks.

Michael.