Re: type consistency of gimple

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Dan" == Daniel Berlin <dberlin@dberlin.org> 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