Re: [lno] Introduce data dependence graph

[Daniel Berlin <dberlin at dberlin dot org>]

> I did not realize initially but
>
> 1) dependence_node_def is a member of a already existing struct that
> is GTY'ed. Which means, I won't be able to completely get rid of GTY
> stuff for this new data structures.
We can un-GTY these structures as well. I'm about to do it.
In general, avoiding having to mark/sweep anything that is fixed size 
that we already actually know the lifetimes of, is a good idea.

> 2) I do not know if in general it is good idea to mix this two
We shouldn't use gc for fixed size structures if we can avoid it.

> 3) I am talking with Sebastian about how we can make DDG available for
> more than one pass.
Okeydokey.
I wasn't aware of this since there was no discussion on the list about 
it.

> 4) I have not collected enough performance numbers for DDG yet. Such 
> number
> can overwhelming favor one memory manager over other.

I've never seen a case where using the gc provides better locality than 
alloc pools (except for the zone gc).

> Do you have such
> data for other stuff?

Yes, look in the archives for the data i posted when i originally 
introduced the alloc pools. I posted data for speedups due to alloc 
pooling bb's and edges, for example (though alloc pooling of these 
things was later undone on the tree-ssa branch due to the need to mark 
things contained within bb's and edges.  Our marker isn't smart enough 
to be able to simply ignore things in non-gc memory, but mark their 
children if they are in gc memory.  We've likely lost a few percent 
performance as a result)
> Do you think it is still a good idea to use alloc_pool?
Yes, but if you think it is too difficult, i'm more than happy to do it.
> --
> Devang