This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch] shrink some cp/parser.c structures
- From: "Zack Weinberg" <zack at codesourcery dot com>
- To: Dan Nicolaescu <dann at ics dot uci dot edu>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Tue, 26 Aug 2003 17:50:52 -0700
- Subject: Re: [patch] shrink some cp/parser.c structures
- References: <200306240018.h5O0IK4X025194@gremlin.ics.uci.edu>
Dan Nicolaescu <dann@ics.uci.edu> writes:
> Some structures in cp/parserc.c can be made smaller by using enum
> bitfields.
>
> Before this patch, on a 32bit machine, sizeof (struct cp_token_block) = 652
> so ggc-page.c would allocate a cp_token_block on a 1024 byte page,
> resulting in a lot of overhead. This patch tries to make sure that
> struct cp_token_block would fit in a 512B block. Is that OK, or is
> 1024B better?
>
> If the patch is OK, please apply it, I don't have CVS commit access.
>
>
> 2003-06-23 Dan Nicolaescu <dann@ics.uci.edu>
>
> * parser.c (struct cp_token): Use enum bitfields.
> (CP_TOKEN_BLOCK_NUM_TOKENS): Make sure cp_token_block fits in a
> 512B allocation unit.
> (cp_parser_token_tree_map_node): Use enum bitfields.
Checked in. Sorry about the two-month wait.
It might be interesting to experiment and find out whether making
cp_token_block bigger would be a good thing. We get 31 tokens per
block with your patch (on 32-bit systems) and I have no idea how
much these are used. It's easy enough to experiment, now; just build
two copies of the compiler with two different settings of the #define
and benchmark.
zw