Re: Creating a prettier flow graph

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

  In message <19981025220413.B17422@dot.cygnus.com>you write:
  > Not a bad idea, really.  I'll keep working on this off and on til it
  > works everywhere and I'll queue behind DaveM's SUBREG stuff.  So if
  > it takes two weeks or a month to get in, so be it.
OK.  However, let's go ahead with the BLOCK_HEAD/BLOCK_END changes though,
those shouldn't be destabilizing and ought to reduce your merge load.


  > FYI, current status is Alpha bootstrap and check with no regressions,
  > Sparc and x86 still don't bootstrap -- probably tablejump differences,
  > as those have given me the most trouble.  I'm also noticing quite a
  > lot of overlap between bits in flow and bits in jump; something to keep
  > in mind for later cleanup.
Move the ADDR_VEC/ADDR_DIFF_VEC into the tablejump itself and be done with
it :-)

I can think of lots of reasons to recast much of jump.c to work on blocks
and edges :-)  Some of them cleanup related, some of them compile-time
performance improvement related (most calls to jump_optimize are to clean up
jumps after other passes have mucked with them -- those calls should not need
to build a partial cfg and scan the insn chain!)

The code which scans the insn chain to transform jumping code into jumpless
code ought to be run more sparingly than the "cleanup" part of the jump
optimizer.

jeff