Mark Mitchell wrote: > Kenneth Zadeck wrote: > > So, I guess my inclination would be to just write out the type > information now, and thereby avoid the dependency on fixing GIMPLE. >
Please don't take this the wrong way, but this approach is the reason GIMPLE is not flat/tupelized, not type consistent *right now*, and why this discussing is even occurring at all. I do not *fault* Diego (and others) for the decision to get a prototype of GIMPLE/tree-ssa first, and clean it up later. As a matter of fact, I would have done the same thing and made the same choices. But we should be aware that most of the time, the hard cleanup never comes because: 1. you quickly gain critical mass of others contributing passes right after the prototype is written (this is what happened with GIMPLE/tree-ssa, even though the thing was changing out from under us, and in fact, a lot of the passes that depended on it don't even exist today, like goto-elimination :P) 2. By the time you are done enough with the prototype that you feel comfortable going back to fix it, the number of things depending on the way the prototype does things has raised the engineering effort to revisit the decisions from person months to person years. 3. It's very hard to do it incrementally, because anything can generate trees that violate the invariants. The only real incremental approach is to pick a point in the compiler, and ensure that everything up to that point generates okay trees, and verify at that point. Then you keep moving the point forward. There are other reasons, of course, such as resource and people management, but hard incrementalness generally means no "spare-time contributors" will attack it. I'm not saying your approach isn't the way to go, I'm just saying that we should be aware that rarely have we actually been able to revisit the the changes we want to revisit later on, when it has come to serious infrastructure. If this is a cleanup we actually want done, IMHO, we should do it first. --Dan
