On Thu, 25 Nov 2004, Diego Novillo wrote:

>
> Jeff noticed that TBAA was creating some alias relations that don't seem
> to make much sense.  For instance, given
>
> ------------------------------------------------------------------------------------struct int_float_s {
>    int i;
>    float f;
> };
>
> int X;
>
> foo()
> {
>  struct int_float_s *x = bar();
>  X = 10;
>  x->i = 3;
>  return X;
> }
> ------------------------------------------------------------------------------------
>
> After TBAA, we had
>
> Variable: x, UID 1, struct int_float_s *, type memory tag: TMT.0
> Variable: X, UID 2, int, is addressable, is global, call clobbered, default def: X_1
> Variable: TMT.0, UID 5, struct int_float_s, is addressable, is global, call clobbered, may aliases: { X }
>
> Jeff's argument is that it's not really possible for a pointer to a
> structure to point to a scalar variable.  If the structure is not type
> compatible with the scalar, then they can't alias.  That makes some
> sense to me.

I had this discussion with someone yesterday actually, and they told me 
the standard says they can (which of course, seems incredibly dumb :P).

This happens to prevent us from optimizing some hot loops in spec, because 
we think the structure pointer aliases some random scalar.

If you wanted to the underlying reason see why this happens, the real 
culprit is  record_component_aliases, in the RECORD_TYPE case.
Note that it makes the TBAA set of every field a subset of the structure's 
TBAA set, making the structure alias set conflict with every type of it's 
fields.


IE it makes

struct foo 
{
 	int a;
 	double b;
 	char *c;
};

conflict with the tbaa sets for int, double, and char (which probably 
means it ends up aliasing everything).

--Dan