Hi, Here is a preliminary result for fold_buildN from my personal tree. I compiled cc1-i files with ./cc1 -quiet -O2 -fomit-frame-pointer -fmem-report -o /dev/null. I used --enable-gather-detailed-mem-stats to see how many nodes and bytes we are allocating for trees. (Thanks Honza!) I then summed up the memory usage of trees.
original patched diff% #nodes 24,234,589 23,577,245 -2.712% #bytes 1,228,797,315 1,205,528,427 -1.893% As far as compile time, I consistently see improvements of 0.1% or a bit more. In case you are wondering what fold_buildN is, fold_build1 (code, type, op0) is equivalent to fold (build (code, type, op0)) except that fold_build1 does not build a scratch node when folding is successful. fold_build2 operates in a similar way. Note that ternary expressions did not take advantage of this fold_build3 mechanism because of the handling of CALL_EXPR in fold_ternary. Since ternary expressions are not as common as binary expressions, I don't except much difference even after we start using fold_build3. Kazu Hirata