On Thu, 3 Mar 2005, Kazu Hirata wrote:
> 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.)
>
> So the question is: Is it worth changing all these? Or should I stop
> folding builtins in fold_ternary?
I don't think this is as bad as it first appears. Most of the
individual fold_builtin_foo functions in builtins.c take the
decomposed CALL_EXPR, i.e. the fndecl, the arglist and the type.
I'm fairly sure those that take the full tree "exp" are relatively
easily tweaked to take fndecl, arglist and type instead.
Following on from the current strategy (game plan?) for fold, I think
we should do something identical with fold_builtin. We keep the
external interface to fold_builtin the same, but underneath the
surface we change fold_builtin_1 to take the individual components.
For the time being we could probably move the:
if (DECL_BUILT_IN_CLASS (fndecl) == BUILT_IN_MD)
return targetm.fold_builtin (exp, ignore);
from fold_builtin_1 to fold_builtin which has the full tree. Once
the transition of fold_builtin_1 to fndecl/arglist/type is complete
we can export it outside of builtins.c, and call this API from your
new fold_ternary.
I appreciate its more work, but it keeps with the philosophy for
this reorganization.
> Thoughts?
Likewise?
Roger
--
