On Fri, 21 Feb 2014, Richard Biener wrote: > On Fri, 21 Feb 2014, Richard Biener wrote: > > > On Fri, 21 Feb 2014, Richard Biener wrote: > > > > > On Fri, 21 Feb 2014, Richard Sandiford wrote: > > > > > > > In a thread a few years ago you talked about the possibility of going > > > > further and folding the attributes into the MEM itself, so avoiding > > > > the indirection and separate allocation: > > > > > > > > http://thread.gmane.org/gmane.comp.gcc.patches/244464/focus=244538 > > > > > > > > (and earlier posts in the thread). Would that still be OK? > > > > I might have a go if so. > > > > > > It would work for me. Micha just brought up the easiest incremental > > > change though, which is > > ... > > > I am testing the following (and also consider it appropriate as a > > fix for the regression PR60291). > > > > Ok for trunk/branch(es)? Now we have many variants to choose from ;) > > Jakub requested statistics for a bootstrap for this one. I get > for r207939 and a --enable-languages=c x86_64 bootstrap > 3609924 mem-attrs created overall without the patch and > 8268976 with the patch (that's a factor of 2.3 and thus "nothing").
One more piece of that statistic, peak number-of-mem-attrs are 121985 without and 298399 with the patch (thats overall number of GC allocations of a mem-attr for the worst compilation unit during bootstrap). That's 4.7MB vs. 11.6MB _aggregate_ memory use (not translatable to the peak number of mem-attrs live, but it certainly bounds it). As it seems that nobody is objecting this patch I'll go ahead and check it in tomorrow. Thanks, Richard.
