This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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

-Sandra


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]