[tree-ssa] un-ssa - part 1

[Andrew MacLeod]

On Tue, 2003-04-01 at 01:50, Daniel Berlin wrote:
> 
> 
> On Mon, 31 Mar 2003, Diego Novillo wrote:
> 
> > On Mon, 31 Mar 2003, Andrew Macleod wrote:
> >
> > > This patch takes a first crack at the un-ssa pass. It implements a basic
> > > partitioner which doesn't do anything different than we have today (ie, it
> > > puts all versions of a variable into the same partition, so we still
> > > aren't taking care of overlapping live ranges.).
> 
> Out of curiosity, why didn't you reuse the conflict graph + partition used
> to do this exact same thing for RTL-SSA.

I never said I wasn't going to be using it. I have every intention on
using it.

> It seems it would be trivial to do the conflict graph reuse (the only part
> that actually does anything related to RTL is conflict_graph_compute, which you'd need to
> rewrite anyway to use for the tree un-ssa. The rest uses standard
> datatypes like int).

It is trivial....

> 
> and at the very least, the partition stuff has 0 RTL dependencies. It's
> even in libiberty.
> 
> You've just reimplemented this stuff.

What did I reimplement? The partitioner implemented here merely makes
partitions. It doesnt do any conflict graph resolution. I need the
partitions before I can do conflict resolution. As I said, this is the
first part.

And, if you look close, you'll notice it does use the partition code
from libiberty... There is some extra stuff to associate the partition
with specific tree variables, and then, more importantly, a compression
vector which reduces the number of partitions down to the range [0..n].

Using the libiberty partitions as is doesnt guarantee a dense range. I
fact, its almost always sparse. When merging 2 partitions, the larger
partition becomes the representative, not the one with the lowest index.
When the partitions are complete, I compress them. I'm merely making
sure when I create the conflict graph, I won't be making it any larger
than it has to be.

What exactly do you think I reinvented?

Andrew