On Fri, Mar 11, 2011 at 02:25:38PM +0100, Richard Guenther wrote: > On Fri, Mar 11, 2011 at 5:23 AM, Nathan Froyd <froy...@codesourcery.com> > wrote: > > This patch series does something similar to what: > > > > http://gcc.gnu.org/ml/gcc-patches/2010-11/msg02491.html > > > > did, only it does it in a cleaner way and it addresses the problem more > > generally. > > > > Eliminating the block field from tree_exp would be another nice-to-have > > for 4.7, but that's not on my radar of things to address at the moment. > > I think removing TREE_TYPE from tree_exp isn't worth it, we do not have > many expression trees left with tuples. Unifying BLOCK with locations > would indeed be nice (but again we don't have many exp trees left).
Well, the patch from last November showed that there are enough expressions left that eliminating a pointer reduces GC memory by ~1%. So I'd say shrinking things would still be worthwhile. > > I have not rigorously measured memory savings with this patch. Based on > > a (very small) sample, this patch saves ~5% of tree memory according to > > dump_tree_statistics...though the amount of tree memory as reported by > > dump_tree_statistics is somewhat suspect, since it doesn't include > > statistics from copy_node_stat. > > I thought I had fixed that ... but appearantly I didn't commit that > part. I have a patch which I will submit for 4.7, so unless you beat me to it... > > The patch series has been bootstrapped on x86_64-unknown-linux-gnu, both > > in its entirety and with sub-patches along the way. > > Did you make sure to enable all languages? And grep for occurances in > backends? I bootstrapped with --enable-languages=c,c++,ada,fortran,java,objc,obj-c++,go. I didn't check for bits in the backends; I can look around, but any backend poking in the fields that got eliminated deserves what's coming. -Nathan