Re: [tuples] memory statistics gathering for tuples

[Aldy Hernandez <aldyh@redhat.com>]

> 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.

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
information, etc.

>> @@ -186,9 +212,14 @@ gimple_alloc (enum gimple_code code)
>>  static void
>>  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;
>
> Here you're just counting the size of the pointer.  You need to call 
> tree_code_size for each operand added.

Are you sure?  It looks like the tree counterpart is only adding
pointers for operands.  See tree_code_size:

    case tcc_reference:   /* a reference */
    case tcc_expression:  /* an expression */
    case tcc_statement:   /* an expression with side effects */
    case tcc_comparison:  /* a comparison expression */
    case tcc_unary:       /* a unary arithmetic expression */
    case tcc_binary:      /* a binary arithmetic expression */
      return (sizeof (struct tree_exp)
	      + (TREE_CODE_LENGTH (code) - 1) * sizeof (tree));

    case tcc_gimple_stmt:
      return (sizeof (struct gimple_stmt)
	      + (TREE_CODE_LENGTH (code) - 1) * sizeof (char *));

Aldy