Re: RFC: GIMPLE tuples. Design and implementation proposal

[Mark Mitchell <mark at codesourcery dot com>]

Ian Lance Taylor wrote:
> Diego Novillo <dnovillo@redhat.com> writes:
> 
>> Following up on the recent discussion about GIMPLE tuples
>> (http://gcc.gnu.org/ml/gcc/2007-03/msg01126.html), we have summarized
>> our main ideas and implementation proposal in the attached document.
>>
>> This should be enough to get the implementation going, but there will be
>> many details that still need to be addressed.
>>
>> Thoughts/comments on the proposal?
> 
> For purposes of LTO, it is essential that we be able to efficiently
> load the IR during the whole program optimization phase.

Right.

> Part of that is almost certainly going to mean having some sort of
> index which will tell us whether to load the IR at all--if the
> functions represented in some .o file are rarely called, then we
> should use the .o file as-is, and not try to further optimize it.
> This is not part of the current LTO plan, but I think it is inevitable
> if we are to avoid an hours-long compilation process.

I agree that this is probably going to be necessary.  Whether that
happens in the LTO "front end" proper, or we rely on the driver (or
even, at first, the user) to prune out uninteresting .o files isn't
clear to me.  There may also be situations where we want to read just
one functions out the .o file (which, perhaps, was compiled with
-ffunction-sections to encourage this) and inline it into other things,
but not read or recompile everything else in the .o file.

> But there is another part: we need to have an IR which can be very
> quickly loaded into memory for further processing.  When it comes to
> loading IR, there is nothing faster than mmap.  That requires that the
> IR be stored in the .o file in a form which can be used directly when
> it is read in from memory.  And ideally that means no pointer
> swizzling: the IR should be usable when loaded without modification.
> And because the link phase can see arbitrary .o files, we can not use
> the PCH hack of requiring a specific memory address.  So that requires
> an IR which is position independent.
> 
> The obvious way to make the proposed tuples position independent would
> be to use array offsets rather than pointers.

And maybe self-relative pointers if you need pointers into things that
aren't symbol-tablish?  A not-so space-efficient approach would be to
allocate out of an ordinary block of memory, using ordinary pointers,
and then swizzle into self-relative pointers at serialization time.
Then, when you deserialize, you could just leave them self-relative, or
swizzle them back.

Man, playing with all these ideas would sure be easier if you could make
a class and overload "*" and "->"....

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713