This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

A headache with fold_ternary and CALL_EXPR.


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]