Re: random thought - optimizer

[law at redhat dot com]

  In message <200107031705.KAA00596@racerx.synopsys.com>you write:
  > Terrific.  This possibly has the potential to get rid of a major g++
  > performance problem: when a temporary object with two or more fields
  > is passed by an inline function, we almost always wind up with dead
  > stores (ADDRESSOF takes care of the one-field case).  Can the SSA
  > DCE optimizer kill the dead stores?  Here's an example of a typical
  > case -- a bit vector with an overloaded [] operator where the operator[]
  > returns a proxy object:
If we can prove the stores are to local memory and that nobody reads them,
yes.  It's a fairly simple extension to the code we have in place.

The SSA DCE optimizer works by marking items which have side effects with
external scope (stores to memory, function calls, returns).  Then we 
recursively follow the use-def chains to mark everything which feeds those
items.

If we know a store is to local memory, then we need not mark the store
during the initial scan to find inherently necessary instructions.  We
would only mark it in response to a load from a memory location which
might overlap with the store.

We don't currently have support for handling memory def-use chains, but
it's something we're definitely going to need to add to the high level
optimizer.

I'm actually a little surprised that the existing DCE code in flow.c
does not catch this case.  It's probably due to the code being conservative
at block boundaries.

jeff