This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
RE: RFC: GIMPLE tuples. Design and implementation proposal
- From: "Dave Korn" <dave dot korn at artimi dot com>
- To: "'Andi Kleen'" <andi at firstfloor dot org>, "'Richard Henderson'" <rth at redhat dot com>
- Cc: <gcc at gcc dot gnu dot org>
- Date: Wed, 11 Apr 2007 16:55:02 +0100
- Subject: RE: RFC: GIMPLE tuples. Design and implementation proposal
- References: <461B175A.1050407@redhat.com.suse.lists.egcs> <m3mz1gnllz.fsf@localhost.localdomain.suse.lists.egcs> <20070411010342.GB25174@redhat.com.suse.lists.egcs> <p73tzvni0us.fsf@bingen.suse.de>
On 11 April 2007 12:53, Andi Kleen wrote:
> Richard Henderson <rth@redhat.com> writes:
>
>> On Tue, Apr 10, 2007 at 11:13:44AM -0700, Ian Lance Taylor wrote:
>>> The obvious way to make the proposed tuples position independent would
>>> be to use array offsets rather than pointers.
>>
>> I suggest instead, if we want something like this, that we make
>> the references be pc-relative. So something like
>
> If you go this way (and require special GC/debugger support) you
> could as well xor next/prev too and save another field.
>
> Adding a xor is basically free and much cheaper than any cache miss
> from larger data structures.
Using a delta is even better than an XOR, because it remains constant when
you relocate the data.
> The only thing that wouldn't work is that when you have a pointer
> to an arbitary element (without starting from beginning/end first)
> you couldn't get previous or next.
You need a pointer to two consecutive nodes to act as an iterator.
However we already discussed the whole idea upthread and the general feeling
was that it's a whole bunch of tricky code for a small saving, so not worth
doing in the first iteration. Maybe as a future refinement. See the earlier
posts in this thread for the discussion.
cheers,
DaveK
--
Can't think of a witty .sigline today....