Hi, These days, I am reorganizing fold. One of my goals is to provide a function like
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 (tmp) return tmp; } 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.) Thoughts? Kazu Hirata