gimple type system

Diego has asked me to look into what would be needed in a gimple type 
system.   This is an issue that has been brought to a head because now 
it is time to merge types for lto.

There are a lot of questions that need to be answered before designing 
such a system and i would like to handle them one by one, rather than 
deal with a thousand threads that go off in a lot of directions.  So for 
now, I would like to limit the discussion to a single question:   "what 
do we want to do in the middle end of a compiler with a middle end type 
system?"

I have a couple of positive answers and one negative answer.  The point 
of this mail is to get a more refined list.  The two positive answers are:

1) Type narrowing.   In an object oriented system, it is generally a big 
win to be able to narrow a type as much as possible.   This can be used 
to then be able to inline method calls, as well as remove runtime casts 
and type checks (this is useless for c). 

2) Inter file type checking.  While this is not an optimization, there 
are reasons why it would be useful to discover types that are mismatched 
across compilation units.

The thing that MAY not be useful anymore is the use of a type system of 
alias analysis.   I would have hoped that danny and richi and all of the 
other people hacking on the alias analysis would have subsumed anything 
that one could have gathered from a type based alias analysis.  If I am 
wrong, please correct me. 

Anyway, there must be other uses of types in either the existing middle 
end or that people have dreams of adding to the middle end in the 
future.   Now is the time to raise your hand before the design has been 
started.

Kenny