[lto] PATCH: add more CALL_EXPR interfaces

Mark Mitchell mark@codesourcery.com
Mon Jul 31 02:01:00 GMT 2006


Sandra Loosemore wrote:

> The point of this set of changes is to introduce a new tree_code_class
> tcc_call which is similar to tcc_expression but with a variable number
> of operands, and make CALL_EXPR and similar lang-specific tree nodes use
> it.  TREE_OPERAND_LENGTH replaces TREE_CODE_LENGTH as the preferred way
> to find the number of operands in a node.

I think that makes sense.

> I haven't yet changed the low-level representation of CALL_EXPRs to
> actually have a variable number of operands.  My plan is to continue to
> use struct tree_exp, and instead of stuffing a TREE_LIST of arguments in
> operand 1, put an INT_CST node there that holds the number of arguments
> following the fixed operands in the node.  It's a little icky, but the
> storage overhead should be negligible (since integer constants are
> shared) and it avoids having to special-case CALL_EXPRs every place
> where compound expressions are being manipulated.

Your idea here is that TREE_OPERAND_LENGTH will use the INTEGER_CST node
that appears first in the CALL_EXPR?  I think that will work fine, and
since you are insulating things from the representation, we can always
change later if we figure out a better way.

I suggest tcc_vl_exp as a better name for the new class (rather than
tcc_call) in that your new representation will work for any
variable-length expression node.  (The macros that are based on the
class name would want to change as well, of course.)  The patch is OK
with that change.

+   /* ??? Should this be EXPR_P instead of EXPRESSION_CLASS_P?  */

Almost certainly, but let's not try to fix that at the same time as
making the other changes.

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713



More information about the Gcc-patches mailing list