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

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

[Sandra Loosemore]

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

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

[Eric Botcazou]

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

If you touched config/sparc, you must test SPARC, at least minimally with a 
cross-compiler.  Otherwise it's OK.

-- 
Eric Botcazou

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

[Richard Kenner]

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

I just checked and there are exactly 11 uses of CALL_EXPR in the Ada front
end.  So it doesn't sound like any large amount of work.

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

[Sandra Loosemore]

Eric Botcazou wrote:
>> 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.
> 
> If you touched config/sparc, you must test SPARC, at least minimally with a 
> cross-compiler.  Otherwise it's OK.

OK, I've testing SPARC.  Doing so actually turned up a bug in our builtins.c 
changes, rather than in anything in config/sparc.  :-P  (Looking at it in more 
detail, I found that some bad changes were accidentally introduced in doing the 
merge from my original version on the LTO branch.)  I've fixed that and 
retested.  We're going to have to resubmit the whole set of patches anyway to 
take care of other comments, so this fix will be in the next attempt.

-Sandra

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

[Eric Botcazou]

> OK, I've testing SPARC.  Doing so actually turned up a bug in our
> builtins.c changes, rather than in anything in config/sparc.  :-P  (Looking
> at it in more detail, I found that some bad changes were accidentally
> introduced in doing the merge from my original version on the LTO branch.) 

Thanks.  Not sure whether you tested native or cross but, in the former case 
and for this kind of somewhat mechanical changes, you can limit yourself to a 
bootstrap/regtest for the C family of compilers.

-- 
Eric Botcazou