This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GC special object sizes


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
unnecessary.

Greetz
Steven



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]