3.4 memory/compile time performance patches, round 2

[Mark Mitchell]

Jan Hubicka wrote:

>Mark,
>I would like to get more of memory patches to 3.4 branch.  
>
I'm getting to the point where I'm not going to want any more such 
patches.  We're about a month out at this point, and yes, 
memory/compile-time is a major issue, but it's also the kind of thing 
where you can introduce weird failures that only occur on some systems, 
and we don't want. that.  So, this is a heads-up: in another week okr 
so, I'm probably not going to accept any more of these patches for 
3.4.0.  We can consider putting them in 3.4.1 if they've been proven on 
the mainline by that point.

>They hit bugs of
>accessing released (and re-used) memory.  One reproduced as wrong code bug on
>IA-64 since 3.3 (http://gcc.gnu.org/ml/gcc/2003-07/msg00780.html), but my patch
>turned it to almost sure ICE.  It shall be finally solved by two patches:
>  
>   http://gcc.gnu.org/ml/gcc-patches/2004-02/msg00106.html
>   http://gcc.gnu.org/ml/gcc-patches/2004-01/msg02931.html
>  
>
OK.

>The other bug has been emitting code on already removed cgraph edge (that
>surely results in misscompilation too, but I don't have testcase).  The fix has
>been approved for 3.4 by Roger, but I managed to use uninitialized variable on
>cc0 targets, so there is followup by Kazy and thus I am asking for re-approval.
>
>   http://gcc.gnu.org/ml/gcc-patches/2004-01/msg03058.html
>   http://gcc.gnu.org/ml/gcc-patches/2004-01/msg03284.html
>
>  
>
OK.

>And finally bugfix with the checking that uncovered this all (the arrays must
>be aligned by 8 when RTXes go to the pool).  I can skip the memset invalidating
>freed entries if it seems less intrusive for 3.4
>
>   http://gcc.gnu.org/ml/gcc-patches/2004-01/msg02536.html
>
>  
>
OK.

>This all is needed in order to put cselib datastructures to allocpool memory.
>This cause huge memory savings as cselib (surprisingly) is major memory
>consumer when it come to GGC.  I have more patches in queue, but they need to
>be approved for 3.4 first.  The savings of these two pathes are bout 40% of
>overall GGC memory allocation on combine.i.  Additional 19% are possible
>by walking further this path, I hope to get them to mainline soon.
>
>   http://gcc.gnu.org/ml/gcc-patches/2004-01/msg02392.html
>   http://gcc.gnu.org/ml/gcc-patches/2004-01/msg02045.html
>
>  
>
I don't understand these comments.  Have these patches been approved for 
mainline?  I'd like to see them tested on the mainline before going on 
the 3.4 branch.

>And one combine.c memory reduction (easy and produced no fallout)
>
>   http://gcc.gnu.org/ml/gcc-patches/2004-01/msg02679.html
>  
>
OK.

>Finally I would feel better if Zack's patch caring uninitialized memory access
>in ia-64
>
>   http://gcc.gnu.org/ml/gcc-patches/2004-01/msg03146.html
>
>  
>
OK.

>I made code checking similar bugs in other frontends.  Perhaps using it in 3.4
>will make it easier to find same bugs in less frequently tested frontends, but
>I would not worry if it is not accepted.
>
>   http://gcc.gnu.org/ml/gcc-patches/2004-01/msg03149.html
>
>  
>
OK.

>Similarly the speedup to extract_insn patch that caused nice difference in the
>SPEC tester compilation time graphs but not very major.  It uncovered the
>uninitialized problems by invalidating the array with enable-checking.  I would
>like to see it in 3.4, but again it is not big deal for me.
>
>   http://gcc.gnu.org/ml/gcc-patches/2004-01/msg02790.html
>  
>
OK.

-- 
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com