Re: [LTO] patch: new CALL_EXPR abstractions in builtins.c

[Paolo Bonzini <paolo dot bonzini at lu dot unisi dot ch>]

>> If I run into some
> > intractable problem with having a tree_exp node with a variably-sized
> > operand array, my backup plan is to store the first few operands in the
> > node and use a TREE_VEC for the overflow; I ran some experiments on
> > some large C programs that indicated that calls with 2 arguments or
> > less account for around 70% of all CALL_EXPRs, so it makes sense to
> > optimize at least the most common cases.
>
> Its disappointing the way that we now have to speculatively construct
> trees (representing the CALL_EXPRs) to test whether a built-in function
> can be folded.  One of the recent pushes with tree-level optimizers has
> been to move towards APIs that allow us to fold/simplify them without
> having to explicitly construct them first, and thereby leak memory to
> the garbage collector.

I agree with Sandra.  Assuming she doesn't have to rely on backup plans 
(*), which would be quite a pity, the heaviness of TREE_LISTs (24 bytes) 
more than offsets the problem of having to construct a CALL_EXPR.

sizeof (tree_list) == 24
sizeof (tree_exp) == 32 + number of operands

CALL_EXPR has 3 arguments now, so its size is 44 bytes.  I'd expect that 
she needs space for the number of operands, which would grow CALL_EXPRs 
to 48 bytes.

So, allocating a CALL_EXPR with 3 arguments will cost 56 bytes; 
allocating two TREE_LISTs for the argument lists is 48 bytes.
The break even point is quite low: for three arguments (which is the 
case for memcmp, memcpy, and so on) we are already at 60 bytes vs. 72.

Also, following Steven B.'s line of reasoning, this could be also quite 
an interesting memory savings for languages like Fortran or C++ where 
bigger argument lists are quite common.

(*) some grepping for fold_.*CALL_EXPR, build.*CALL_EXPR, and 
TREE_CODE_LENGTH suggests that CALL_EXPR are rarely expected to have 
three arguments, and that switching from TREE_CODE_LENGTH to TREE_LENGTH 
would not be hard.

Paolo