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

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

(Given Sandra's latest answer this may be moot, but still my last 2 
cents come...)
> The answer, with current mainline, is that fold_builtin_sin
> gets called no less than eight times!
>   
I would have said a dozen, so you're surprising me in an unexpected way! :-)
> Hence your analysis of break-even points has to factor the
> memory we save on the single CALL_EXPR, which is all thats
> need to represent the above call to "sin" in SSA form,
> vs. the overhead we'll leak from the eight calls to fold!
>   
Note that the overhead only applies to fold_build3.  Calls to 
fold_ternary (CALL_EXPR, ...) luckily are just absent from GCC: most of 
the time they use fold_build3 or even build3, and for these it is not a 
problem that we have to construct a CALL_EXPR before folding.

fold_builtin is also quite rare, but every time we can call fold_builtin 
(or fold_call_expr as it would be called after this patch), we already 
have a CALL_EXPR tree at hand that we can reuse!  That may be luck, but 
that also means that we can (and the patch will) reuse the same 
CALL_EXPR.  Likewise, the patch ensures that fold (call_expr) does not 
generate a new tree.  This special casing might be considered a source 
of headaches, but at least it does not have the leakage problem you 
mentioned.

(I understand that the patch is so huge, that this is easily overlooked).
> You'll also understand why many middle-end folks
> strongly believe that trees should be folded at construction
> time, and when modified, rather than repeatedly calling fold
> on the same expression.
>   
Surely I do too, and Kazu's implementation of fold_buildN and 
fold_{unary,binary,ternary} was very welcome to me too.

Paolo