On Fri, Jul 18, 2008 at 11:25 PM, Kenneth Zadeck <[EMAIL PROTECTED]> wrote: > 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.
Hah. You are definitely wrong. > 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. We already have a middle-end type-system. It is unfortunately mostly implicitly defined by the assumptions we make and the information we extract from the types. I don't think you can just go and define a type-system - after all, what would be the result of such a definition? Instead there are some goals we want to reach: 1) reduce the amount of data related to types (and declarations) during optimization 2) canonicalize "types" if their difference does not matter for the current and further stages of compilation (like we do now say all integral types with the same precision and signedness are "the same") For both of the above a prerequesite to actually really "unify" types (not treating them the same, but actually getting rid of either in favor of another) is to handle debug information properly. The plan is to emit debug information for the source-level state of types early and refer to that from declarations via a unique identifier. One question would be if we want to gradually lower types (for example flatten structures, unify bit-precision integer types to modes, etc.) or if we just want to do one step after/during gimplification (we have a second step at RTL expansion of course). Richard.
