PATCH: CALL_EXPR representation part 0/9 (table of contents)

Sandra Loosemore sandra@codesourcery.com
Sat Feb 10 15:10:00 GMT 2007


This is the first in a series of messages with the patches to merge the changes 
to the CALL_EXPR representation that were made on the LTO branch back to 
mainline.  Since this is a very large set of changes that touch many parts of 
the compiler, I've broken it into separately-posted chunks to make it a little 
easier to digest and review:

1: The actual tree.{h,c,def} changes and associated documentation change.
2. A very large chunk of changes to builtins.c and fold-const.c.
3. All the random middle end and other changes in the main gcc directory.
4. All the back end changes in gcc/config.
5. C front end changes.
6. C++ front end changes.
7. Java front end changes.
8. OBJC front end changes.
9. Fortran front end changes.

In spite of the size of these patches, most of them are very repetitive and 
mechanical.  In a nutshell, here's what's changed:

* CALL_EXPRs are now represented using tcc_vl_exp, a class of variable-length 
expressions whose first operand encodes the length.  Arguments are stored 
directly in the CALL_EXPR instead of in a separate TREE_LIST.

* Most former uses of TREE_CODE_LENGTH should now use TREE_OPERAND_LENGTH, which 
knows about tcc_vl_exp.

* New accessors (CALL_EXPR_FN, CALL_EXPR_ARG, etc) are provided to get at pieces 
of CALL_EXPRs.

* Former uses of build3 to construct CALL_EXPR objects are changed to use one of 
build_call_list, build_call_array, build_call_nary, or build_call_valist, 
depending on the form of the arguments.

* Many uses of build_function_call_expr are changed to use the new variadic 
version build_call_expr, to avoid having to construct a temporary TREE_LIST for 
the arguments.

* The various expand_builtin_FOO functions which formerly took an arglist 
parameter now take the entire CALL_EXPR instead.

* The various fold_builtin_FOO functions which formerly took an arglist 
parameter now take the individual argument exprs as parameters instead.  (The 
asymmetry with respect to the expand functions permits folding of builtins 
without first allocating a temporary CALL_EXPR, much as the fold_buildN 
functions work.)

This change breaks the Ada front end.  Back last year when I undertook this 
project on the LTO branch, the Ada maintainers said they would take 
responsibility for updating their code if/when the changes made it back to 
mainline.  Brooks, Lee, and I can help out with that if necessary, but we'd 
really like to get the other changes committed first before they undergo another 
round of bit-rot.  I know there is also more work that could be done on the 
other front ends to avoid constructing unnecessary temporary arglists, for 
further memory use improvements rather than correctness.

We've tested these changes on i686, x86_64, powerpc, and ARM, so far.  I can do 
sparc and/or pa-risc on request if anybody is particularly worried about those 
platforms.  We also tested all of the C front end and infrastructure changes 
with --enable-checking=all so that we would get extra diagnostics about 
incompatible uses.

Thanks in advance to reviewers for looking at this whopper patch!  :-)

-Sandra



More information about the Java-patches mailing list