This is the mail archive of the
mailing list for the GCC project.
Re: [tuples] memory statistics gathering for tuples
On 3/14/08 8:00 AM, Aldy Hernandez wrote:
3- The easiest approach will probably be comparing statement lists versus
gimple sequences. We still haven't gone through making sure we release all
the expression trees that are gimplified.
Yes, I'm noticing benchmarking is going to be non-trivial, and probably
not an exact science until we have exact code paths, and we can
benchmark right before RTL generation, not after gimplification like I
will be forced to do now.
Yes, there are many things that have changed place, so we have to make
sure we count the exact same thing in trees and tuples.
While I don't expect huge memory savings, calibrating this should not be
hard. If you find that tuple sizes seem bigger than trees, it's almost
a certainty that the counts are not being collected right. In any case,
memory savings is going to be just a side-effect of the redesign, it's
not one of the important parameters in my mind. The only blocker would
be if tuples result in worse memory utilization or compile-time performance.
I think comparing statement lists versus gimple sequences will be the
most straightforward way. Of course I will have to adjust the size of
tuples for extra things we have in there, like USE/DEF information, BB
Yeah, or make sure that we also count the size of stmt_ann() in trees.
And not just sizeof(), we need to add up all the sizes for individual
fields in the annotation.
Here you're just counting the size of the pointer. You need to call
tree_code_size for each operand added.
@@ -186,9 +212,14 @@ gimple_alloc (enum gimple_code code)
gimple_alloc_ops (gimple stmt, size_t num_ops)
- stmt->with_ops.op = ggc_alloc_cleared (sizeof (tree) * num_ops);
+ unsigned int size = sizeof (tree) * num_ops;
Are you sure? It looks like the tree counterpart is only adding
pointers for operands. See tree_code_size:
Oh, right. The operands are always counted separately in each of their