This is the mail archive of the
mailing list for the GCC project.
Re: [LTO] patch: new CALL_EXPR abstractions in builtins.c
- From: Sandra Loosemore <sandra at codesourcery dot com>
- To: Roger Sayle <roger at eyesopen dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Tue, 27 Jun 2006 14:00:37 -0400
- Subject: Re: [LTO] patch: new CALL_EXPR abstractions in builtins.c
- References: <Pine.LNX.firstname.lastname@example.org>
Roger Sayle wrote:
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 suspect a more agressive restructuring of this code, introducing new
APIs, such as fold_unary_builtin, fold_binary_builtin, etc... where we
explicitly pass arg0, arg1 ... argN in the common cases (most builtins
don't have a variable number of arguments, and often only one or two
operands/arguments) would address the majority of the memory regression
incurred by this change.
Yes, I had also considered this. It seemed to me that the overhead of
speculatively consing up a CALL_EXPR was probably no greater than that of the
current code speculatively consing up a new TREE_LIST to hold the arguments
before trying to fold. If more aggressive restructuring the code as you suggest
is in line with current policy, though, I agree it's a better way to do it. I
can go off and hack on it some more and submit a revised patch when I'm done.
Thanks for the feedback. :-)