Some more comments (this time section by section and a little more thought out):
2.1: Requirement 1: a good question is how does ICC or even XLC do this without doing anything special? Or do they keep around an "on-the-side" database. (Requirements 2-4 assume Requirement 1) Requirement 5: is perfectly fine as far as I can tell. (Requirement 6 assume Requirement 1) Requirement 7: seems prefectly fine, maybe going more into which are incompatible options, -ftrapv is a good example, -fwrapv is another very good example. 2.2: Requirement 8-10: prefect. 2.2.1: Maybe I am missing something but I don't see where common symbols are mentioned. Are they really just weak? 2.2.2: So are pointer pointing to type1 the same type as reference pointing to type1? The way I read the document, pointers and references are interchangable. Maybe an explited statement saying they are the same type or not. (3: all assume requirement 1.) 3.2: does that mean GCC would begin using BFD also or I am reading that wrongly? Or we are could read in all file formats using a new interface which mean we duplicated all the BFD reading code. A good question about this whole 3 section is how does ICC or XLC handle this. I understand we don't want to repeat their mistakes but not mentioning what they do seems like it was not as thought through as it really was. 4: Requirement 11: Very good. Requirement 12: I still am secticial of all these source-anaylsis programs. Now export is a different reason, but the problem with using the rest of the requirements for this is wrong as first there is no way to repesent overloaded sets, all the C++ specific code (though we could extend the bytecode but is harder if we don't design it in the first place). Requirement 13 and 14: are no brainers. Just one note about 14, stack based bytecode does not correspond to GIMPLE TREE representive that well. An infinite register one with no stack except for ADDRESSABLE variables. Also the Rationale of 14 says we go in and out of SSA, is that expensive? for an example PHI insertion is O(N log(N)), see PR 18594 for an example of where this can take a long time. 4.1: assumes requirement 1. Yes dwarf3 is well defined but has it really ever been used for this purpose before, that seems like a question which should be answered here. 4.2: semi does not statifies requirement 14, see above. There should be mention of other bytecodes so it does not look like only those two were looked at since there are some major ones like LLVM which is gaining a huge movement inside Apple for an example. WIRL is another one which comes to my mind. the registers: The registers of the GVM correspond one for one with the local variables at the GIMPLE level. >From reading that, does that mean we actually have all variables in registers and that the stack is not that useful? An example of what the bytecode would look like with that saying is: push a push b add pop c which is the same as c = a + b. Are in a non stack based bytecode: add c, a, b Just like a three operand ISA. But doesn't that mean we really have a non stack based bytecode with just instructions which act on the stack and that stack will be empty after one GIMPLE instruction is executed? Then why have a stack at all as no part of the compiler as far as I can see will ever generate code which does stuff like: push a push b add push c add pop d Which is equivalent to d = (a+b)+c. Now a pre-link time optimizer could do it if it can prove that the (a+b) is only used that once. What we would produce right now with gimple is: e = a+b; d = e+c; Or to the stack bytecode: push a;push b; add; pop e; push e; add; pop d; But we need an extra pass to optimize away the pop/push if we are already out of SSA. Now if the registers correspond to GENERIC variables, we would be produce d = (a+b)+c; -- Pinski
