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]

Re: [RFC] Tightening up the type system


>>>>> "Andrew" == Andrew Haley <aph@redhat.com> writes:

>> > It's an interesting view.  I'm pretty sure that we violate this is the
>> > Java FE in a few places, but perhaps we shouldn't.  The trouble is
>> > that the GENERIC type system has never been so well-defined.

I'd like to see us continue toward the goal of having generic and
gimple be well defined and fairly strict about checking -- ideally
with documentation preceding implementation.  I think we can make it
much easier to write front ends, and much easier to look at some
random tree and decide whether or not it is actually valid.

So, I'm in favor of adding the checks, with the caveat that if it
turns into a big morass it should perhaps be put off until the next
stage 1.

>> Maybe we should if we lowered GIMPLE one more step, but for now we tie
>> the optimizers to the FE's type system.

Andrew> Yeah, but surely the front end can generate trees that are not legal
Andrew> in its own type system.  For example, Java doesn't have a (void*)
Andrew> that's assignable to anything, but we generate trees of type (void*)
Andrew> when lowering.

I'd say that, in an ideal situation, it is up to the front end to
decide what kind of type system it exposes to gimple.  For Java this
might be "java types plus void*", the semantics of which we must
define.  In particular it seems to me that this need not be identical
to the language's type system.

Tom


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]