Re: [RFC] ignoring type alias conflicts between structures andscalars

[Jeffrey A Law <law at redhat dot com>]

On Thu, 2004-11-25 at 10:33 -0500, 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.
More correctly my argument is that a structure reference can not
conflict with a global variable.  For the structure reference to
be able to conflict with a global you must have a way to embed a
global named object within some other object.


> However, the front end says that those two types are alias compatible,
> meaning that we could store into X via x.  So, I'm confused.  I
> discussed this a bit with Nathan and Joseph on IRC.  Nathan pointed me
> to some section in the C standard that seems to support the fact that
> indeed TMT.0 should alias X.
Ignore the front-end type system.  Think about the problem for a while.
Show me a way to embed one global object within another.  (OK, you
might be able to do it with an alias attribute, but presumably we
can look at the _DECL node to detect that oddball case.



> The attached patch implements the idea of ignoring alias relations
> between structures and scalars that are not type compatible.  It
> survived bootstrap and testing on x86, ia64, x86-64 and ppc.  However, I
> have zero confidence in it.  If the types cannot really conflict,
> alias_sets_conflict_p() should tell me so.  I shouldn't need to short
> circuit it this way.
I don't think that patch is as-is safe.  You have to know something
about the objects.  Specifically that one is in global memory and
that the other object is referenced via simple structure references
(as opposed to pointer indirections).

Hmm, maybe we're losing each other on the structure reference stuff;
I might be responsible for that by writing x->y when I meant x.y
The former has pointer indirection, at which points all bets are
likely off.

Hmmmm.




Jeff