Ian Lance Taylor wrote: > 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. > > The issue is not the io. The current organization, with each function arranged in its own section is designed to so that that section can be memory mapped in. The question how much work is it going to be to transform what is mapped in into the working representation.
The unswizzling of the pointers will be a certain amount of work and will most likely touch a fairly dense amount of the program representation vs parsing it which will read everything and create a new representation of everything. All that I was saying was that that parsing is not obviously the wrong way to go if it means that the subsequent data structures are better suited for the kinds of manipulations that we are going to make. > >> 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 >
