Re: Question re: SSA Aggressive Dead Code Elimination

[law at redhat dot com]

  In message <20010627134827.A18499@tornado.cygnus.com>you write:
  > > Now note carefully the single insn in block #1.  The value in the RHS is
  > > a redundant computation.  If we implement dominator based optimizations
  > > during conversion to SSA per Morgan's book we'll be able to optimize away
  > > that computation when converting to SSA which would leave us with somethi
  > ng
  > > like this instead:
  > > 
  > Why?  SSA analysis should not munge the program.  Convert to SSA
  > and then let PRE and/or partial DCE do their magic.  Or did you
  > mean that?
Because it's bloody trivial and makes the rest of the ssa optimizers do
less work.  Think of it like the difference between local vs global cse.

I strongly recommend you review the section on dominator optimizations in
Morgan's book.  You'll find that these optimizations are so trivial to
implement during the SSA conversion that it's totally silly not to do so.


  > > I see a couple obvious options.  One would be to not remove instructions
  > > during dominator optimizations -- we'd go ahead and generate a new tempor
  > ary
  > > at insn 95 and assign it the value r30.  The PHI node at insn 148 would
  > > reference that new temporary and when insn 148 was marked important, insn
  > > 95 would be marked as important then insn 93 would be marked as important
  > .
  > > 
  > Yes.  The error was removing a computation that was only
  > partially redundant.
No, the computation was totally redundant because we use the value computed
in a dominator block and copy prop the result to its uses.

jeff