On Wed, Nov 16, 2005 at 02:26:28PM -0800, Mark Mitchell wrote: > http://gcc.gnu.org/projects/lto/lto.pdf
In Requirement 4, you say that the function F from input files a.o and b.o should still be named F in the output file. Why is this requirement more than simply having the debug information reflect that both names were originally F? I see you go to some length in section 3 to ensure actual symbol table duplicates, and I don't know why. The rest of the requirements look good. I cannot immediately think of anything you've forgotten. Section 2.2.1 "invalid if and of" s/and/any/ By focusing on c99 inline functions, you've forgotten the facts of gcc inline functions. I'll give you a guess as to which set of semantics are actually used in practice. Note that gcc's inline semantics are a superset of both C++ and c99, and that gcc doesn't actually implement c99 semantics at all. Section 2.2.2 You don't specifically mention arrays with differing ranges, but identical numbers of elements. E.g. 0 to 5 and 1 to 6. Section 3.4 I don't think I understand how you plan to not duplicate code from ld to locate the set of object files. The only way I can think of is for ld to actually extract the objects into new temporary files. Perhaps I've forgotten how much effort is involved here, but I can see it being easier to just duplicate this code and forget it. Section 4.1 Some more detail on what you have in mind wrt mapping scopes would be nice. My initial thought is that you wouldn't need anything special at all. Just refer to the scopes from within the IL by offset within the CIE. Perhaps I'm missing something that makes this hard. Section 4.2 What is the rationale for using a stack-based representation rather than a register-based representation? A infinite register based solution would seem to map better onto gimple, making it easier to understand the conversion into and out of. The required stacking and unstacking operations would seem to get in the way. C.f. plan9's inferno, rather than jvm or cil. I'll say that I do like the notion of emitting the type and symbol tables as normal dwarf3 output. Especially since your proposal seems to call for regular code to be emitted simultaneously, so that ld -r can work. r~
