Re: [tuples/LTO] RFC: houghts on auto-generating GS_* data structures

[Kenneth Zadeck <zadeck at naturalbridge dot com>]

Ian Lance Taylor wrote:
> Diego Novillo <dnovillo@google.com> writes:
>
>   
>> But, first, I'd like to know what folks think about this.  Would it be
>> generally useful for us to have the IL data structures auto-generated
>> this way?  I can see the benefits in the reader/writer.  But also, we
>> are going to have to re-implement the reader/writer when we move GIMPLE
>> out of the tree data structures.  OTOH, we will probably change them,
>> add new codes and having them autogenerated may have other advantages.
>>     
>
> If we can use mmap to read the IL--which I personally think is going
> to be a requirement for speed during the LTO phase--then this issue
> does not necessarily arise.  Rather than see work on this, I
> personally would prefer to see work toward developing an IL which can
> be read using mmap (possibly with pointer swizzling during the write
> phase, which is less time critical).
>
> If it turns out that auto-generation is still useful during the write
> phase, I have no problem with it.
>
> Ian
>   
Ian,

I do not necessarily believe that you are wrong, but you are  not
"obviously right" either.

I understand the experience base that you come from: that of object code
and linkers and in that world, doing this is an unquestionable "yes". 
But there are some features of that world that are not going to carry
over here:

In the linker world, you read (map) in a block, apply some relocations
*in place* and write the block out [I get to ignore all of the work you
do to figure out the relocations because it is irrelevant to this
discussion.]

In the lto world we will be reading in a function and then hacking on
it.  Many (most) of those hacks are not in place changes, but adding,
deleting and rearranging instructions into the stream. 

Doing in place mapping puts severe restrictions on the kinds of storage
managers that are going to be available to the rest of the compiler. 
They are going to have to be aware of the instructions (and other
structures) that have been mapped in vs the instructions that are newly
created and thus can be recovered. 

This is not impossible, it is merely hard.  And the extent that it ends
up slowing down both the development process and the resulting compiler
is the basis for me saying that your idea is "not obviously correct".

There is a strong argument for making developing the tools to generate
the middle end data structures, even if we do not use them for lto: 
1) It will force us into a discipline where we cannot do the braindead
overloading that make the trees so difficult to manipulate.  This is
only doable if we start now before the rot sets in. 
2) It will allow us to do lto serialization if we decide to. 
3) If we decide we want tools to be able to write out, edit, modify and
re-inject intermediate code into the compiler, the in and out part are
easily derived from such a high level description.

 
Kenny