Re: Updating the CFG on the fly?

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

  In message <14377.13804.320548.473638@ongaonga.elec.canterbury.ac.nz>you writ
e:
  > Yes, it can occur when we have nested natural loops sharing the same
  > loop header.  I've got a testcase for this but do not yet have a good
  > idea of how common this occurs.
  > 
  >      |
  > +-->(2)<--+
  > |__/  \   |
  >       (3) |
  >        |  |
  >       (4)-+
What does this look like at the source level?  And what does it look like as
soon as we've finished initial RTL generation?

  > I had envisaged that the jump optimiser would fix this up once the
  > loop had been optimised.
Only by cross jumping, which happens just before final output.  And our cross
jumping isn't very powerful.

When I was looking at edge splitting stuff a year or so ago I was looking
at similar kinds of problems, and most of the time jump didn't clean things
up (and cleaning them up was pretty far out of the scope of what jump was
going to be able to do without being converted to use the cfg to drive its
work).

jeff