IMA vs tree-ssa

[Dale Johannesen <dalej at apple dot com>]

.When compiling intermodule (IMA), objects that are defined in multiple
files have their types unified so that all copies of the object refer 
to the
same TYPE_DECL.  This is not done for objects local to a function,
which has the effect that the same type can have multiple TYPE_DECL
nodes used for it, even within the same function.  The example at  the
end demonstrates; compile with IMA, and the first assignment statement
winds up referring to different nodes for struct rtx_def on the two 
sides.
(This causes no problem in this particular example.)

There are several places where tree-ssa does type comparison by
comparing TYPE_MAIN_VARIANT() for equality.  This doesn't work with
IMA, and leads to several different ICEs in various SPECmarks (you
can probably figure out which one the example came from :)

Has anyone else run into this, and thought about fixing it?

My first thought was that this should be fixed by having IMA unify all
copies of the type.  But looking at the code, I don't think this would 
be easy
to get right, and Geoff, the author of IMA, doesn't like it:

> I don't think that would work:
>
> - You'd need to be sure it doesn't change language semantics
> - You'd need to make debugging information correct
> - I'd like to get rid of this final 'merging' pass; it's slow, it 
> doesn't work with -fno-unit-at-a-time, and now that we've thrown out 
> the GCC-specific features that required it, it's not necessary.
>
> I would ask why code in tree-ssa seems to need to compare types.  
> Maybe it needs a language-independent comptypes() that looks at things 
> like field sizes and offsets.  Maybe the language frontend, should be 
> responsible for casting types so that the middle-end doesn't need to 
> be concerned by any of this.

Now I'm thinking along these lines:  make a langhook that calls 
comptypes() for C-based languages,
and devolves to x==y for the others (or calls the comptype-equivalent 
if there is one; I know nothing
about those language FEs).  That will not make the non-C languages any 
worse, and since IMA isn't
implemented for them, there isn't currently a problem there.  Whoever 
implements it for those languages
will need to provide a comptypes() equivalent.

Comments?

/**  s1.c  */
#include "s1.h"
extern rtx recog_operand;

/** s1.h **/
typedef struct rtx_def { int a; int b; } *rtx;
extern rtx recog_operand;

/** s2.c  */
rtx recog_operand;
int foo() {
  rtx *r0, t1;
  r0 = &recog_operand;
  t1 = *r0;
  return t1->a;
}