This is the mail archive of the
mailing list for the GCC project.
Re: GC special object sizes
- From: law at redhat dot com
- To: Steven Bosscher <s dot bosscher at student dot tudelft dot nl>
- Cc: Diego Novillo <dnovillo at redhat dot com>, Geoff Keating <geoffk at geoffk dot org>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 05 May 2003 20:10:31 -0600
- Subject: Re: GC special object sizes
- Reply-to: law at redhat dot com
In message <1052185839.724.216.camel@steven>, Steven Bosscher writes:
>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)
Yup. FWIW, it was actually cheaper to go ahead and use an additional
pointer in tree-common to get us to the locus information. Depending
on precisely how the current locus information work progresses in the
mainline, we may be able to zap than (then again, we may not, I don't
really know yet).