Re: RFC: GIMPLE tuples. Design and implementation proposal

[Ian Lance Taylor <iant at google dot com>]

Richard Henderson <rth@redhat.com> writes:

> On Tue, Apr 10, 2007 at 10:53:19AM -0700, Ian Lance Taylor wrote:
> > As you know, we have a lot of basic optimizations in fold-const.c that
> > operatee on trees.  We also have a lot of basic optimizations in
> > simplify-rtx.c that operate on RTL.  These sets of optimizations are
> > independent implementations.  What can we do to avoid implementing a
> > third set of basic optimizations that operate on GIMPLE?
> 
> Perhaps I misunderstood what Diego was proposing, but I 
> would have thought the subcode would continue to be the
> tree PLUS_EXPR, and not a GS_PLUS something.
> 
> With that, build_foldN does essentially what we want,
> without having to regenerate tree nodes on the input side.

I'm having a hard time seeing it.  fold_build2 calls fold_binary; I
agree that if we can handle fold_binary, we can handle fold_build2.
But fold_binary takes trees as parameters.  How are you thinking of
calling it?

Admittedly this is going to be more of an issue for a hypothetical
tree^H^H^H^Htuple combiner than it is for run of the mill tuples.

Ian