Re: Minor SSA cleanups

[law at redhat dot com]

  In message <873d8thnnk.fsf@cgsoftware.com>you write:
  > You mean in terms of time taken, or what?
In just about any way you can think of.

  > Because i'm made it completely incremental.  So we can just share the
  > same df structure between all the ssa passes, and incrementally update
  > it.
But all I've seen a need for us chains of uses, which given a doubly linked
list can be incrementally updated just as easily with less cost.

  > If you meant in terms of interface, I agree, it's probably
  > heavyweight, because it can do so much more.  But it's intended to be
  > shared across multiple passes.
So what.  If we don't need all that additional functionality, why pay the
price.  ie, what is it buying us?


  > Sure, but why not reuse what is there.
a. It's not really there.
b. It's far far more than what I think we need.

  > It provides a nice interface to doing all these things. Whenever we
  > add another lightweight hunk of code, we seem to end up, even though
  > we don't intend it, with duplicated code everywhere.
Yes, that's clearly the downside.  

  > > And yes, you can do some indexing into the various tables we've got lying
  > > around, but why bother.  If we record the edge, then no indexing into the
  > > tables is needed when we go to insert the copies when we eliminate the
  > > phi nodes.
  > Well, like I said, for anything more than simple following phi node
  > edges, it's worthless.
  > I'm not sure which optimization you are doing, but in SSA CCP, GVN,
  > and PRE, it just wasn't enough.
Huh?  All the embedded block # gets used for is the conversion from SSA back
to normal form.  It's affect on SSA-CPP is nil as I would expect its effect
on any other SSA optimizer to be.

jeff