more analysis on update_flow_info() crashes on sparc/rs6k

[Jeffrey A Law]

  In message < 199810181414.HAA25285@dm.cobaltmicro.com >you write:
  > I split this into two SFmode moves:
  > 
  > (insn 82 31 84 (set (reg:SF 24 %i0)
  >         (reg:SF 16 %l0)) -1 (nil)
  >     (nil))
  > 
  > (insn 84 82 62 (set (reg:SF 25 %i1)
  >         (reg:SF 17 %l1)) -1 (nil)
  >     (nil))
  > 
  > Flow created the original DEAD & UNUSED notes for (%i2/%i3) because
  > the subreg store to word 0 has undefined results on the other portion
  > of this complex value.
  > 
  > My splits cause this information to be lost.
Interesting case.  In essense, the splitters have removed the undefined
operations on other parts of the value, which make the notes invalid.

What does the chain-o-notes look like if we don't run the post reload flow
pass?  I'm curious how this worked before.

One thought might be to emit some combo of use/clobbers so that the undefined
actions on the other parts of the value are still visible, that might give the
code somewhere to hang a note.  I think combine does something like this on
occasion.

Which brings up another possiblity -- what does combine do?  I suspect this
kind of thing can happen there too.

We could probably just ignore this case too.  This code runs early enough that
ignoring a death note shouldn't cause the scheduler to abort later.  If we took
this approach it would be nice if we could identify it with some accuracy so
that we could keep the sanity check for other cases.

jeff