Kenneth Zadeck <[EMAIL PROTECTED]> 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
