This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: A headache with fold_ternary and CALL_EXPR.
- From: Zack Weinberg <zack at codesourcery dot com>
- To: Kazu Hirata <kazu at cs dot umass dot edu>
- Cc: gcc at gcc dot gnu dot org, roger at eyesopen dot com
- Date: Thu, 03 Mar 2005 20:15:56 -0800
- Subject: Re: A headache with fold_ternary and CALL_EXPR.
- References: <20050303.230034.124085449.kazu@cs.umass.edu>
Kazu Hirata <kazu@cs.umass.edu> writes:
> It turns out that the CALL_EXPR case of fold_ternary needs the
> original tree like so. (Notice a reference to t.)
...
> If we want to change fold_builtin to take operands like op0, op1, and
> op2, I would have to change so many things that depend on
> fold_builtin. (Note that the subroutines of fold_builtin also depends
> on fold_builtin in a sense that they need the original tree, one whose
> TREE_CODE is CALL_EXPR is available.)
In my half-considered opinion, the fact that CALL_EXPR counts as a
ternary operator is an accident; function calls probably ought to get
their own fold_call() primitive or something like that. Perhaps this
is what fold_builtin already is. Of course it would be nice not to
have to construct the CALL_EXPR if it's just going to be folded out...
zw