This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] type safe trees
Geoff Keating wrote:
On 24/06/2004, at 9:19 PM, Mark Mitchell wrote:
Geoff Keating wrote:
If you're using the current HEAD, you should know that there's a bad
performance bug in which the GC settings are wrong when
--disable-checking is in effect. If you're seeing GC happen when
building combine.c in a bootstrap, you either forgot
--disable-checking, you're seeing this bug, or you need to go buy
more RAM (even my laptop, with 256Mb of RAM, doesn't GC while
building combine.c with the computed --param ggc-min-heapsize=65536).
Would you please describe this bug in more detail? Do you know how
to fix it?
Wasn't the above description sufficient?
I was looking for information like in what way the settings were wrong,
or under what circumstances it manifests, or what change caused it. It
wasn't clear to me whether you knew exactly what was going on (and were
maybe even in the prcoess of fixing it) or whether you had just observed
a mysterious problem.
The symptom is that the GC parameters are locked at 4k, even with
--disable-checking.
Thanks for explaining.
No, I don't know how to fix it. I don't even know if it's really in
FSF GCC, it may be a merge bug into our local tree.
OK; I'll hope for the latter. :-) Thanks for the heads-up.
Also, I understand what you're saying about CONST_DECLs living only in
PCH memory which is never read -- but what about things like TREE_LISTs
or VAR_DECLs that get built a lot even after the PCH has been read in as
the remaining code is processed. Do you have any ideas about how
profitable it might or might not be to shrink them? (We can get lots of
these nodes as templates are instantiated and as code is processed.)
Also, on the identifier table issues you mention, I was actually
thinking about how to reorganize that stuff today. We should avoid
stepping on each other in that area. I think there are some data
structure improvements we should make and also some ways in which we can
seriously improve the case of entering/exiting class scopes, which
happens a ton.
--
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com