[PATCH][RFC] A GIMPLE and "GIMPLE type system" verifier

[Daniel Berlin]

On 01 Jun 2007 07:47:56 -0700, Ian Lance Taylor <iant@google.com> wrote:
> Richard Guenther <rguenther@suse.de> writes:
>
> > On Thu, 31 May 2007, Diego Novillo wrote:
> >
> > > Well, without having a properly defined type system for GIMPLE, I don't
> > > know how we can implement a verifier for it.  Seems to me like we should
> > > do that first.
> >
> > Btw, how do you define "type system"?  Or asked differently, what do
> > we want to define or specify for a GIMPLE type system?  Possibly we
> > are thinking of different things here - as you can see from the checker
> > code I am most interested in where the "type system" meets the IL.
>
> I think the minimal way to define "type system" here would be to say
> that code in GIMPLE never needs to call the front end to find out what
> to do.  That is, any differences between front ends are explicitly
> represented in the IR.
>
> Basically, we need to define type compatibility in GIMPLE, and require
> the frontends to generate correctly typed code.  And we need to define
> precisely what should happen when we convert one type into another:
> that is, what do NOP_EXPR, CONVERT_EXPR, and VIEW_CONVERT_EXPR realy
> mean when changing types?
>
> > Is there any existing work on defining the GIMPLE type system?
>
> At the mini-summit Danny proposed, in essence, that we simply declare
> that GIMPLE type compatibility to be equality of TYPE_MAIN_VARIANT,
> and that the frontends be required to generate type-safe code under
> that metric.  This is not as insane as it sounds as the only languages
> which use a non-trivial definition of the types_compatible_p langhook
> are in fact C and C++.
>

Right.
The other option i proposed was to add a new field called
TYPE_EQUIVALENCE, representing the equivalence set of a type.  The
gimpliifer would simply unify all types using some equivalence metric
(structural, name, whatever), applied uniformly to all types.  Two
types are equivalent if they have the same TYPE_EQUIVALENCE.

The advantages of this are that you still have the original types
around, for two purposes
1. TBAA  set computation
2.  Debug info generation

You could also just generate a set of new types, but then you have to
address the alias set issue (either by merging the TBAA sets, or
providing a unique key that you could somehow pick the TBAA set up
with), and debug info.