This is the mail archive of the
mailing list for the GCC project.
Re: [lno] Introduce data dependence graph
We can un-GTY these structures as well. I'm about to do it.
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.
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 twoWe 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.
I wasn't aware of this since there was no discussion on the list about
4) I have not collected enough performance numbers for DDG yet. Such
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.