Re: Question re: SSA Aggressive Dead Code Elimination

[law at redhat dot com]

  In message <20010627145256.A19895@tornado.cygnus.com>you write:
  > > 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 didn't read you right, sorry.  I read it as if you meant doing
  > all these transformations *while* computing where phi terms go and
  > what not.  Pre/post processing is what I had in mind.
Basically the dominator opts happen during the renaming process.  ie, you've
already figured out where the PHI nodes go (but don't know their precise
operands).  Basically the opts collapse down to simple management of a hash
table, pushing an existing SSA register name instead of a new one when
redundancies are found and doing some simplifications on hunks of RTL (via
simplify_rtx).



  > Ah, yes.  I missed the copy propagation.  Damn RTL :)
:-)   It's actually kind of nice that cprop happens as a side effect of
the dominator optimizations.  I've already noticed that I have an easier
time analyzing hunks of RTL in SSA form with all the copies optimized away :-)

  > When you re-wrote the phi term, you took away the information of
  > where the original definitions came from.  This prompted DCE to
  > linearize the path.  Shouldn't we keep that information in the
  > phi term, then?
Almost.  I never rewrote the PHI term (it's not strictly necessary in this
optimizer, though I'll be doing that shortly).

The code got linearized because the DCE optimizer didn't record that if a
PHI node is important then each predecessor of the block containing the
PHI node has become important (since edges record semantic information when
in SSA form).  A little tidbit that Morgan neglected to mention in his book :-)

Twiddling the dead code optimizer to handle this tidbit causes all the right
things to happen.

jeff