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

[Ian Lance Taylor <iant at google dot com>]

Kenneth Zadeck <zadeck@naturalbridge.com> writes:

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

I'm not sure I completely agree, or perhaps I don't completely
understand.  You can rearrange something that you mmap in, assuming
you copy it in.  Or just think the read system call, it doesn't really
matter.  I just think that if we have to take some action on every
instruction we read in--i.e., parse it from bytecode into the internal
representation--the I/O itself will be significant for LTO on a large
program.

Yes, memory management is more complex, but not that much more
complex.  Note that our GC system already understands what type of
page an object is allocated in.


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

It's fine with me if you or somebody wants to tackle it.  I agree that
it brings benefits.  I'm just not sure it's the most productive thing
to work on.

Ian