Re: [tree-ssa][RFC] An interface to fold(tree)

[Roger Sayle <roger at eyesopen dot com>]

On Mon, 20 Oct 2003, [iso-8859-1] Pop Sébastian wrote:
> On Sat, Oct 18, 2003 at 10:18:02PM -0600, law@redhat.com wrote:
> >  >Just to agree with Jeff, I much prefer this approach.
> >  >
> >  >Instead of having a single fold_tree with an arbitrary number of
> >  >arguments, some of which may be NULL_TREE,  I'd suggest pushing
> >  >the role model of "simplify_rtx" even further,  and have several
> >  >"baby-folds": fold_unary, fold_binary, fold_ternary, etc...
> > Yea, that's probably better.
> >
>
> Ok, I've gave it a try in this direction.


Good interfaces are created by design, not out of convenience.
Your factoring of code seems to be driven more by the local variables
that a live in the original function than by good design practices.


> + tree
> + tree_fold_goto_bit_ior (tree type,
> + 			tree arg0,
> + 			tree arg1,
> + 			int wins,
> + 			tree t,
> + 			tree t1)


Here, for example, the last three arguments "wins", "t" and "t1" are
relics of the original fold implementation.  Most disappointing is that
"t1" denotes a temporary variable and doesn't need to be passed to this
function at all!  If you look at the following code it is overwritten
almost immediately.


> + {
> +   if (integer_all_onesp (arg1))
> +     return omit_one_operand (type, arg1, arg0);
> +   if (integer_zerop (arg1))
> +     return non_lvalue (convert (type, arg0));
> +   t1 = distribute_bit_expr (BIT_IOR_EXPR, type, arg0, arg1);
> +   if (t1 != NULL_TREE)
> +     return t1;
> +


I think if we hope to improve fold from its current structure, it can't
be done by blissfully cutting-and-pasting the existing code.  Changes
such as your proposed patch can make things harder to fix not easier.


Now that mainline has entered stage3, my strong recommation is that we
don't attempt to completely overhaul GCC's constant folding until CVS
unfreezes for 3.5.  These clean-ups are not critical to tree-ssa, and
don't qualify as bug-fixes for mainline.  Making radical changes on the
branch without being able mirror them on mainline (or vice-versa) will
just make the task of merging tree-ssa and mainline that much harder.

I think everyone agrees that fold could be restructured, but now is not
the time to do it, and this way is not the way to do it.  In the
mean-time, there are plenty of bugs that need fixing on both mainline
and tree-ssa that should have higher priority during the current stage
of development.  The faster these issue get addressed, the earlier we
can thaw for the much needed clean-up work.

Roger
--
Roger Sayle,                         E-mail: roger@eyesopen.com
OpenEye Scientific Software,         WWW: http://www.eyesopen.com/
Suite 1107, 3600 Cerrillos Road,     Tel: (+1) 505-473-7385
Santa Fe, New Mexico, 87507.         Fax: (+1) 505-473-0833