[Bug preprocessor/53525] Performance regression due to enabling track-macro-expansion

["jimis at gmx dot net" <gcc-bugzilla@gcc.gnu.org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53525

jimis <jimis at gmx dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #27520|0                           |1
        is obsolete|                            |
  Attachment #27523|0                           |1
        is obsolete|                            |

--- Comment #13 from jimis <jimis at gmx dot net> 2012-06-04 04:49:13 UTC ---
Created attachment 27550
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27550
Diff of all changes versus the 20120513 snapshot.

I think I'm closing to a final version of this fix. The attached patch contains
all of the above mentioned changes, plus it fixes the memory leaks. This
bootstraps fine and passes tests on x86 with no regression. 

Instruction count has been reduced from 2201M downto 2108M, which is only 30M
higher than having track-macro-expansion (TME) turned off. Unfortunately actual
runtime was improved less, so we gained back almost 50% of what we had lost by
enabling TME. In short running the same test as above, with this (macro5)
patch, gives:

2108 M instr
31692 KB RAM
0.760s

In a few words, I introduced four (!) new obstacks inside struct cpp_reader for
allocating the tokens from macro argument expansion, their virtual locations,
the virtual locations of arguments, and the virtual locations of other macros. 

I'm not sure whether this is an elegant solution but growing obstacks for
nested scopes is much more intuitive than reallocating arrays. I'd appreciate
any comments on my "TODO" notes in this patch, which mostly concern whether I
should move other allocations to obstacks as well.

Finally, my patch still contains the additions to obstacks (obstack_mark,
obstack_release). I'll try submitting them to glibc but since they are in the
obstack.h header file, they work even when using the libc obstacks so I guess
they can be committed in the gcc tree.