This is the mail archive of the
mailing list for the GCC project.
Re: zack's todo list
- To: zackw at stanford dot edu
- Subject: Re: zack's todo list
- From: Mark Mitchell <mark at codesourcery dot com>
- Date: Mon, 13 Nov 2000 10:21:59 -0800
- Cc: gcc at gcc dot gnu dot org
- Organization: CodeSourcery, LLC
- References: <20001113095606.K235@wolery.stanford.edu>
* GC performance
- Get strings out of the GC arena. (patch submitted)
- Get Laurnyas and Alexandre's patch to make ggc-page usable without
mmap applied, so we can throw away ggc-simple.
- Split arena into separate tree, RTL, misc pools.
- Dual mark bits for trees; avoids millions of calls to ggc_set_mark.
(Requires separate pools.)
- Look into not rounding all allocations up to powers of two.
(Saves large amount of memory.)
- Better GC statistics.
These are all good things. We want to go to a generational collector,
methinks, and I think I know how -- it's actually not a major change
once trees and rtl are in their own pools.
* Junk allocations
- Make __FUNCTION__ et al allocate the string only when used.
(Avoids pointless allocation of strings and decl structures for
every function. May mean we don't need prune_unused_decls
- Lazy make_decl_rtl - avoid allocating symbol_ref RTLs when they
won't ever be used.
- Don't create a complete IDENTIFIER_NODE for DECL_ASSEMBLER_NAME.
Likewise, these are good -- but may not be required for 3.0. I don't
see these as necessary; the GC work may be in order to get back lost
* Makefile cleanups
- Run mklibgcc at configure time and merge output into the big
- Compile libiberty for build, get rid of private copies of several
libiberty files (Kaveh has patch already?)
- Do installation in separate shell script?
Probably not necessary for 3.0 -- but probably not risky either.
- Templatized hashtab.c (avoids abstraction overhead, minor speed
- Update cpp.texi
Mark Mitchell firstname.lastname@example.org
CodeSourcery, LLC http://www.codesourcery.com