Well before GCC 4.x there was an attempt that a few of us worked on to try to move the algebraic simplifications from combine to simplify-rtx.c, just like we put tree folding in fold-const.c. At that point, combine just becomes "bookkeeping". The problem with that approach was what to do with such things as nonzero_bits and num sign bit copies.
Actually, simplify-rtx.c now uses nonzero_bits and num_sign_bit_copies: these ask combine for the value in the case of pseudos, via the "RTL hooks" mechanism. The same RTL hooks mechanism allow combine to try using its (clobber (const_int 0)) idiom in gen_lowpart, for example. It was done in 4.1 or 4.2, I don't remember, and it allowed quite a few simplifications to be moved from combine_simplify_rtx to simplify-rtx.c.
It is possible to move a lot more indeed. The problems are mainly these two:
1) what to do with (clobber (const_int 0)). This should be not so much of a problem thanks to validate_change, but I'd be weary of having such CLOBBER rtx-en in REG_EQUAL notes!
2) a lot of this is hard to be done incrementally. For example, it is hard to move any one of simplify_and_const_int, make_compound_operation, expand_compound_operation, force_to_mode, simplify_shift_const without moving the others. This means that the patches would be huge. Or it could be possible to move simplify_comparison, but it is a 1200-line function so the almost-mechanic changes needed to move it would be also very hard to review.
The problem with fold_rtx is the other way round; it's hard to move the lookup logic into simplify-rtx.c even using RTL hooks.
That means we could merge CSE and combine and do a *lot* more than we ever were able to do before while having the code for both passes be much simpler.
Unfortunately, we should not forget CSE's secondary functionality, which is to act as garbageman for the GCSE pass.
Paolo
