This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

3.4 memory/compile time performance patches, round 2


Mark,
I would like to get more of memory patches to 3.4 branch.  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

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

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

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

And one combine.c memory reduction (easy and produced no fallout)

   http://gcc.gnu.org/ml/gcc-patches/2004-01/msg02679.html

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

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

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

Honza


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]