This is the mail archive of the
mailing list for the GCC project.
Re: GC special object sizes
- From: Steven Bosscher <s dot bosscher at student dot tudelft dot nl>
- To: Diego Novillo <dnovillo at redhat dot com>
- Cc: Geoff Keating <geoffk at geoffk dot org>,"gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: 06 May 2003 03:50:38 +0200
- Subject: Re: GC special object sizes
- References: <1051633938.7385.68.camel@steven><email@example.com> <1051641364.7385.80.camel@steven><1051717586.731.160.camel@steven> <firstname.lastname@example.org>
Op di 06-05-2003, om 01:35 schreef Diego Novillo:
> On Wed, 2003-04-30 at 11:46, Steven Bosscher wrote:
> > Diego, you get this because if this goes on the trunk, you should _not_
> > merge it into the tree-ssa branch, because tree_common is 8 bytes larger
> > on the branch, so two operand tree_exps are 32 bytes.
> OK. Should I define TREE_EXP_SIZE to something different on the
> branch? I don't like the idea of having to undo the patch every time I
> do a mainline merge.
The trouble is that for tree-ssa, there are two additional pointer
fields in tree_common (bah, yuck, yech, eeeeuuuwh) so that tree
expression nodes with two operands occupy 32 bytes on machines with 32
bits address space (i.e. all ia32 machines). We already _have_ a page
for that so the extra page is redundant.
It probably doesn't hurt much to create the extra page, it just means
we're creating a page order for something we already have a separate
page order for.
If there was an elegant check to see if an extra_order_size was a power
of two, I would implement it so that we'd ignore extra page orders for
such sizes in init_ggc in ggc-page. (This would also allow us to have
fire-and-forget page orders for things like identifier nodes which have
different sizes for each language.)
But so far I couldn't come up with something (haven't tried anything)...
Summary: It probably does not hurt to merge the patch, it is just