Re: Updating the CFG on the fly?

[Jeffrey A Law <law at cygnus dot com>]

  In message <14376.59362.865480.164820@ongaonga.elec.canterbury.ac.nz>you writ
e:
  >  > Pictures and a concrete example would help.
  > 
  > OK, let's start with a simple example where we want to perform loop
  > invariant code motion on a natural loop with header node (3), having
  > multiple edges coming into it (1-3 and 2-3) from outside the loop.
  > 
  >    (1)  (2)
  >     |    |
  > +->(3)<--+
  > |   |
  > +---+
  > 
  > Currently, any insns hoisted out of the loop have to be inserted on to
  > all the edges coming into the header from outside the loop (in this
  > case 1-3 and 2-3).  So instead I wanted to create a loop pre-header
  > node (4) so that hoisted insns only had to be added to edge 4-3.
Right.  So the question is does this actually happen in normal code.  rth
and I were discussing this today; we both think it should be rare, but we
could be wrong.


  > Another example that trips up the loop optimiser is when we generate
  > two natural loops with the same loop header node.  Something innocuous
  > like:
  > 
  > for (i = 0; i < (foo ? 4 : 8); i++) {} 
The transformation you're suggesting is going to add an additional branch on
the path which continues the loop -- probably not a particularly wise idea.

[ I'm assuming that your cfg left out the loop exit from nodes 3 & 4.


  > produces a CFG of the form:
  > 
  >      (1)
  >       |
  > +--->(2)<---+
  > |   /   \   |
  > +-(3)   (4)-+
  > 
  > I was looking at transforming this into
  > 
  >      (1)
  >       |
  >      (2)<---+
  >     /   \   |
  >   (3)   (4) |
  >     \   /   |
  >      (5)----+

jeff