Re: sh fixup_addr_diff_vecs patch

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

  In message <200010270305.e9R35kd01187@vieques.cygnus.com>you write:
  > Hi Joern.
  > 
  > I've found a case where cse and jump optimization is changing:
  > 
  > (jump_insn 178 177 179 (parallel[ 
  >             (set (pc)
  >                 (plus:SI (reg:SI 97)
  >                     (label_ref 0)))
  >             (use (label_ref 180))
  >         ] ) -1 (nil)
  >     (nil))
  > 
  > into:
  > 
  > (jump_insn 178 218 179 (set (pc)
  >         (label_ref 155)) -1 (insn_list 218 (nil))
  >     (expr_list:REG_DEAD (reg:SI 1 r1)
  >         (nil)))
  > 
  > because the jump table after cse looks like this:
  > 
  > (jump_insn 181 180 182 (addr_diff_vec:HI (label_ref:SI 180)
  >         [ 
  >             (label_ref:SI 155)
  >             (label_ref:SI 155)
  >             (label_ref:SI 155)
  >             (label_ref:SI 155)
  >             (label_ref:SI 155)
  > 	etc, etc etc
  > 
  > This happens because the, albeit very inefficient, C code is:
  > 
  > 	switch (foo) {
  > 	case blah:
  > 		x = 99;
  > 	case blah2:
  > 		x = 100;
  > 	case blah3:
  > 		x = 101;
  > 
  > there is no break statement, so all the intermediate stores into "x"
  > are dead.  Which causes cse to do all sorts of magic.
  > 
  > Now, the problem shows up in machine dependent reorg
  > (fixup_addr_diff_vecs) which gets all confused because it can't find
  > the "casesi_jump_2" pattern in the chain of instructions-- obviously
  > because it got rewritten into something else.
  > 
  > Here's a patch to fix the problem.
The problem is the ADDR_DIFF_VEC should have been deleted when the jump
which originally referenced the ADDR_DIFF_VEC was changed into a normal
jump.  That is the bug, twiddling fixup_addr_diff_vecs to work around that
bug is wrong.

If you want to detect this situation, then (IMHO) the place to do it is
in verify_cfg or something like that (since it's a generic issue) and it
should be under the control of ENABLE_CHECKING.

jeff