Re: [PATCH] Canonical types (1/3)

[kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)]

> TYPE_CANONICAL is about the language idea of "the same type".
> TYPE_MAIN_VARIANT is "the cv-unqualified variant of this type, treating
> typedefs as different."  So, I don't think they're really the same.

Right. I didn't say they were.  What I was trying to say is that they
both represent similar concepts: types that are closely related, with the
definition of "closely" being different.

> We could get rid of TYPE_MAIN_VARIANT, make TYPE_NEXT_VARIANT a circular
> list, and find TYPE_MAIN_VARIANT by walking TYPE_NEXT_VARIANT until we
> find a cv-unqualified type.   That would save memory, but not
> necessarily time.  However, if we typically only have at most 2 variants
> (unqualified and "const"), then it might be a win.

That's the direction I was headed.  Certainly "in the old days" the vast
majority of types had just one variant and, a small number had 2 and
essentially none have more.  I don't think that's changed.

What I'm a little concerned about is whether if we ask for a const variant
of some type, we can accept a const-variant of any type that has the
same TYPE_CANONICAL value.  I don't know enough about the relevant language
issues to know if we can, but I suspect so (though not if we allow TYPE_ALIGN
to be different; however it's hard to see how those are "the same type").