PATCH: detect dead memory stores with auto increments

[Jeffrey A Law]

  In message < 200008072029.VAA18410@net.HCC.nl >you write:
  > The store to a[i].amp1 was not removed because the sore to a[i].amp2 was
  > changed into an auto increment. To solve this I changed flow to handle
  > this. If a post increment/decrement or modify is used and any previous
  > memory store refers to the same memory location we can delete this store.
  > I tested this on the c4x. It passes the torture tests.
  > 
  > 	Herman.
  > 
  > 2000-08-07 Herman A.J. ten Brugge <Haj.Ten.Brugge@net.HCC.nl>
  > 
  > 	* flow.c (insn_dead_p): Detect dead memory stores with auto increments.
This is basically OK.  Just one question -- why the MEM_IN_STRUCT_P check?
I don't see why it would be needed, and if it's needed, don't we need to
have a similar check for MEM_SCALAR_P.

You can check it in with whatever STRUCT/SCALAR code you think is necessary.

-- Future work -- 

While looking at the code, it occurred to me that we might find more dead
code by working on reverse extended basic blocks.  ie, we don't have to
forget everything we know at a block boundary.

Why?  Consider the following CFG with all edges flowing down.

    1
   / \
  2   3
   \ /
    4

The reverse extended blocks are (4, 2, 3) and (1).  A reverse extended basic
block is a maximal sequence of nodes ending with a branch node that contains
no other branch nodes (where a branch node is one that has > 1 successor).

If we have a store in block 2 and a store to the same location in block 4,
then we can delete the store in block 2 as it is redundant.

It might be interesting for someone to play with extending dead code 
elimination
to work on reverse EBBs (if someone wants to work on that, they may be able
to use some stubbed code I have for building normal EBBs, let me know).

Since I mentioned I've got EBB code -- I've also got tweaks to the local
register allocator which allow it to work on extended basic blocks that I
need to clean up and submit.

jeff