[EMAIL PROTECTED] (Richard Kenner) writes: > > My conclusion at the end was, the best speed up possible, isn't to > > mess with the callers, but rather, to get types canonicalized, then > > all the work that comptypes would normally do, hopefully, just all > > goes away. Though, in the long run those quadratic algorithms have to > > one day die, even if comptypes is fixed. > > My confusion here is how can you "canonicalize" types that are different > (meaning have different names) without messing up debug information. > If you have: > > Foo xyz; > > and you display xyz in the debugger, it needs to say it's type "Foo", not > some similar-but-differently-named type. > > Or maybe this is C++-specific and isn't relevant in C, so I'm not going to > understand it.
The way to canonicalize them is to have all equivalent types point to a single canonical type for the equivalence set. The comparison is one memory dereference and one pointer comparison, not the current procedure of checking for structural equivalence. This assumes, of course, that we can build an equivalence set for types. I think that we need to make that work in the middle-end, and force the front-ends to conform. As someone else mentioned, there are horrific cases in C like a[] being compatible with both a[5] and a[10] but a[5] and a[10] not being compatible with each other, and similarly f() is compatible with f(int) and f(float) but the latter two are not compatible with each other. Fortunately C99 6.2.7 paragraph 2 says "all declarations that refer to the same object or function shall have compatible type; otherwise, the behavior is undefined." I think that is as close as C gets to the ODR, and I think it may give us the leeway we need to build an equivalence set for these awful cases. Ian
