Kenneth Zadeck wrote: >>>>> I have had some discussions with Honza and Diego about the type >>>>> consistency at the gimple level. They told me that Andrew was in the >>>>> process of making gimple properly type consistent.
I think that there is widespread consensus that GIMPLE should ideally be type-consistent, in the sense that (as you say) the only places where types change is via explicit type-casts (e.g., NOP_EXPRs). The same optimization that you want to perform at the LTO level (i.e., not writing out types for every nodes) is also one that would pay off in terms of memory savings at the TREE level. (In my opinion, it doesn't really matter if MODIFY_EXPR is treated as doing an implicit conversion; the important thing is that the set of places where implicit conversions are performed be both limited and documented. If we save tons of TREE nodes by saying that MODIFY_EXPR is defined to do an implicit conversion, as if the right-hand side had a NOP_EXPR to convert it to the type of the left-hand side, then that might be a perfectly valid memory optimization on TREE.) So, the question is one of timing: do we build LTO to work with the current not-type-consistent GIMPLE, or do we fix the compiler to generate type-consistent GIMPLE first and then go on to LTO? I think this is a question of priorities. It's relatively straightforward to fix the compiler to generate type-consistent GIMPLE: you write consistency-checking routines and then you just fix all the problems that arise, by inserting explicit type-conversions at the source of the offending inconsistency. However, while straightforward, that's probably person-months of effort. >From an engineering point of view, it would probably be best to fix GIMPLE first; that has other positive side-effects, and it would avoid doing LTO work that might have to be undone. However, from a project-management point of view, it might be best to go for proof-of-concept on LTO first, writing out the types for nodes explicitly. I would assume that this wouldn't be a lot of additional effort; i.e., while it will waste a lot of space, it won't waste a lot of programmer time. You could also strike a middle ground: write the consistency checker (Danny may have already done this) as a separate pass and put it on the LTO branch. Run it before writing out LTO information. If the input is inconsistent, abort; otherwise, write out LTO information. That lets you write out the more compact representation, but still avoid trying to fix all of GIMPLE right now. (You just have to fix whatever is required for proof-of-concept programs to work.) It does mean, though, that you're essentially committing to the type-safety work before we can make LTO part of mainline, which is probably adding several person-months to the overall project. Or else you have to assume that you may have to go back and write out the type information later, in order to get LTO into mainline. So, I guess my inclination would be to just write out the type information now, and thereby avoid the dependency on fixing GIMPLE. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
