This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [lno] Introduce data dependence graph

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.

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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]