On Sat, 12 Feb 2005, Nathan Sidwell wrote: > I question if it is better to fold early. As I've said before, I think > the optimizations that fold performs should be turned into a proper SSA > optimization phase% -- that can be repeatedly applied as necessary.
As for a proper tree-ssa optimization pass, I believe Andrew Pinski's proposed tree-combiner pass which attempts to merge/combine consecutive tree statements and check whether the result can be folded, would fit your description. However, the utility of early fold to the GCC compiler is much greater than simply compile-time evaluating expressions with constant operands. One of the reasons that fold is so fast, is that it can rely on the fact that all of a trees operands have already been folded. In fact, much of the middle-end makes or can make use of the assumptions that constant operands to binary operators appear second, that a NOP_EXPRs only appear where needed, that NEGATE_EXPR never wraps another NEGATE_EXPR and that "x+x" and "2*x" are represented the same way. For example, left to it's own devices a front-end would produce a potentially unbounded tree for "!!!!!!!!!!!!!!...!!!!x". Whilst, it might be desirable to reproduce such ugliness in source code analyis tools, the fact that GCC currently only has to work minimal trees (compact by construction) both improves compile-time and memory usage. Another example is the some front-ends (cough, g++, cough) love calling save_expr at any opportunity, even on constant integers and string literals. If it wasn't for the middle-end/fold only creating such tree nodes as necessary, many analyses/transformations, would be significantly complicated. As several front-end people have suggested, calling fold whilst constructing parse trees shouldn't be necessary (as shown by the shining examples of g77 and GNAT). In reality, many of the transformations performed by fold (most? as I expect expressions with constant operands are actually fairly rare at the source level) are purely to tidy up the inefficiencies or incorrect tree representations constructed by the front-ends. If it isn't clear from the name fold_buildN, these interfaces are designed to apply the invariants expected when building trees. In the further flung future, the buildN interfaces may become deprecated and even further still trees might be marked read-only (i.e. const) outside of the middle-end (allowing static trees and more middle-end controlled tree sharing). Bwa-ha-ha-ha-ha (evil laugh)! Roger --
