This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On Fri, Jul 18, 2008 at 11:25 PM, Kenneth ZadeckI stand corrected. I could hope.
<zadeck@naturalbridge.com> 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.
Here, I think that you are wrong. You can first start with a series of requirements and only keep the information that is necessary to satisfy the requirements. We currently have a type system that is defined by: here is what the c front end used to provide for use, and then we grafted on what the front ends would provide for use and now we have a mess.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?
I would like to settle this lowering issue after i get an inventory of the uses we want to make of the type information.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.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |