>>>>> "Dan" == Daniel Berlin <[EMAIL PROTECTED]> writes:
Dan> I do not *fault* Diego (and others) for the decision to get a Dan> prototype of GIMPLE/tree-ssa first, and clean it up later. FWIW my experience writing a front end was that trees remain weird to work with -- sometimes fixing type compatibility will fix a bug, other times it doesn't seem to be necessary. It's much simpler to deal with interfaces which (a) document what is required and (b) complain if you do something wrong. The less fuzzy the middle end is about what it accepts, the better. Dan> 1. you quickly gain critical mass of others contributing passes right Dan> after the prototype is written Dan> 3. It's very hard to do it incrementally, because anything can generate Dan> trees that violate the invariants. A few things that may help: * A pass to do type checking (this has been kicked around for a while AIUI) * Just have gimplification fix up types * Have a flag so that, post-gimplification, build* will abort if a non-type-safe tree is created. It seems like this would be a simple way to track down the passes that are creating un-typesafe trees. As to performance regressions that would occur with "useless casts" -- those seem like latent bugs to me. Tom
