Re: Detecting casesi insns

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

  In message <199910210946.KAA03860@cam-mail1.cambridge.arm.com>you write:
  > 
  > Another thing that sprung to mind was that JUMP_LABEL is dangerous as it 
  > stands if a target has any insns that can contain more than one code 
  > label.  In these circumstances there are many occasions where you have to 
  > rescan the whole insn to ensure that you have fixed all the labels within 
  > it (this is precisely the problem with the casesi insn, which contains two 
  > labels, the label preceeding the ADDR_VEC and the label for the default 
  > branch).
  > 
  > I wonder if it would make sense for JUMP_LABEL to be made into a vector?  
  > It could then contain a list of all the labels mentioned in an insn.  For 
  > some optimizations it might make sense only to try with the first element 
  > of the vector, but when fixing other things up it would save having to 
  > rescan the insn; in particular, it would be a good reminder to programmers 
  > that there isn't guaranteed to be exactly one label to fix.
Not sure on this one.

A lot of the stuff we do with JUMP_LABEL could go away if we dis-connected the
insn chain for most of the opt passes and worked primarily on the lists of
insns within basic blocks and edges between blocks (cse, local-alloc, etc) or
strictly on the edges between blocks (jump).

We'd need some way to re-wire things so that we can emit assembly code, which
would imply that each out edge in the BB structure would have a condition
associated with it.  With that kind of model we don't really even need/want
jump insns to appear in the insn chain until possibly just before final
output.

But that's further off and something we'll want to experiment with before
deciding it's a "good thing".

jeff