Richard Henderson <[EMAIL PROTECTED]> 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
