Hi, I am planning to reorganize fold as suggested by Roger Sayle on IRC.
The shortest way to describe this mini project would be to develop the tree equivalent of simplify_gen_ARITY and simplify_ARITY in the RTL world. Doing so should reduce the number of scratch tree nodes created when idioms like fold (buildN (...)) are used. Hopefully, we should be able to pick up some compile-time improvement along the way. Step 1 ------ Split fold into fold_unary, fold_binary, etc. Make fold a simple dispatch function into fold_unary, fold_binary, etc. The interfaces are kept exactly the same. We would pass one tree as the only argument. Each function returns the folded tree or the original tree. No change to the external interface (outside of fold-const.c) is made. Step 2 ------ Eliminate the direct use of the original tree. For example, fold currently has things like fold_binary_op_with_conditional_arg (t, ...) and fold_range_test (t) These functions, as they stand, would not work without the original tree "t". We need to change their interfaces so that they will work with decomposed arguments like code, type, op0, and op1. Again, no change to the external interface (outside of fold-const.c) is made. Step 3 ------ Change fold_unary, fold_binary, etc, so that they will return NULL_TREE instead of the original tree when no folding is performed. Change fold accordingly so that it will still return either the original tree or the folded tree (but not NULL_TREE). Again, no change to the external interface (outside of fold-const.c) is made. Step 4 ------ Change fold_unary, fold_binary, etc so that they will take decomposed arguments like code, type, op0, op1. At this point, fold_ARITY functions should be just like their RTL equivalent, simplify_ARITY. Change fold accordingly. Again, no change to the external interface (outside of fold-const.c) is made. Step 5 ------ Provide fold_buildN as extern functions. Step 6 ------ Convert fold (buildN (...)) to fold_buildN. This is very mechanical but very disturbing at the same time. We need to coordinate thing first with various people, especially those maintaining branches. One thing I can say is that converting a little by little would be even more disturbing than the one-shot conversion as people with patches spanning several files may have to adjust their patches several times. Step 7 ------ Export fold_ARITY. Step 8 ------ Look for places where we can use fold_ARITY and convert them. Step 9 ------ Enjoy the result and continue to hack GCC. :-) Summary ------- The point is to do as much cleanup and reorganization as possible without changing the external interface before making the big conversion. By the way, the past proposals from Roger Sayle are found at: http://gcc.gnu.org/ml/gcc-patches/2003-10/msg01514.html http://gcc.gnu.org/ml/gcc/2004-01/msg00560.html Both of these are along the same lines as above. Any comments? Kazu Hirata
