Re: patch for mips flow problem, including test case

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

  In message <tx1pvc3am49.fsf@cygnus.com>you write:
  > 
  > > The addition of (use (label)) to tablejumps is an anachronism.  That was
  > > necessary in the early days, but it has been unnecessary ever since the
  > > REG_LABEL reg notes were added.
  > 
  > The USE method is the only way used by rtlanal.c:computed_jump_p,
  > which is used by flow, to distinguish tablejumps from generic computed
  > jumps.
But we could just as easily identify tablejumps by an ADDR_VEC/ADDR_DIFF_VEC.
That's how Cygnus's block merging code and edge splitting code identifies
table jumps.

Actually I wouldn't mind looking into attaching the ADDR_VEC/ADDR_DIFF_VEC
to the tablejump insn itself.  It would avoid two ugly problems:

	* flow current puts the tablejump insn and the ADDR_DIFF/ADDR_DIFF_VEC
	into different basic blocks (which causes problems for gcse, block
	merging, and edge splitting)

	* If we stop flow from putting them in different blocks, then we have
	be concerned about code which assumes that it won't find a JUMP_INSN
	except at the end of a block (the scheduler comes immediately to mind).

  > The notes on REG_LABEL in rtl.h emphasize its use in non-jump insns.
  > If it can be used in a jump insn to indicate the associated table,
  > that should be indicated there.  Might we want labels on tables of
  > addresses to be handled differently from labels that would be targets
  > of jumps or address-of-code-label operations?
If we can differentiate them, it can help when building the cfg and with
optimizers/analyzers which work on the cfg like egde splitting and block
merging.

  > >	  There are a number of ports nowadays that
  > > don't bother to include the (use (label)) in tablejump patterns.  The MIP
  > S
  > > is one.  PA is another (see the casesi0 pattern).  There may be others.
  > 
  > Okay, then the PA will probably fail the test case I added, if casesi0
  > gets used.
It does get used. :-)  It's due for another rewrite though.  The current code
is extremely unfriendly to the dynamic branch prediction scheme on the PA8000
class processors.

jeff