This is the mail archive of the
mailing list for the GCC project.
A headache with fold_ternary and CALL_EXPR.
- From: Kazu Hirata <kazu at cs dot umass dot edu>
- To: gcc at gcc dot gnu dot org
- Cc: roger at eyesopen dot com
- Date: Thu, 03 Mar 2005 23:00:34 -0500 (EST)
- Subject: A headache with fold_ternary and CALL_EXPR.
These days, I am reorganizing fold. One of my goals is to provide a
fold_ternary (code, type, op0, op1, op2)
without taking a tree that would be obtained by
build3 (code, type, op0, op1, op2)
So we need to eliminate a reference to the original tree, that
ie, the result of the build3 above.
It turns out that the CALL_EXPR case of fold_ternary needs the
original tree like so. (Notice a reference to t.)
/* Check for a built-in function. */
if (TREE_CODE (op0) == ADDR_EXPR
&& TREE_CODE (TREE_OPERAND (op0, 0)) == FUNCTION_DECL
&& DECL_BUILT_IN (TREE_OPERAND (op0, 0)))
tree tmp = fold_builtin (t, false);
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?
IMHO, the latter isn't a totally crazy idea because the CCP folds
builtins by directly calling fold_builtin, and Diego is planning to
run CCP at several places, even at an early stage of tree SSA
optimizations. (Currently, we depend on DOM to propagate constants,
but it doesn't fold builtins IIRC.)