Re: [RFC] ignoring type alias conflicts between structures and scalars

Re: [RFC] ignoring type alias conflicts between structures and scalars

[Richard Kenner]

Ooops: I meant that the conflicts relation is *symmetric*.

Re: [RFC] ignoring type alias conflicts between structures and scalars

[Diego Novillo]

On Thu, 2004-11-25 at 16:03 -0500, Richard Kenner wrote:
>     But if we just have a structure reference and a global variable, we
>     won't ever have this problem.  The aliasing code doesn't look at
>     those.  It only ever looks at pointers vs addressable variables.  It
>     doesn't care about other variables.
> 
> You lost me.  Isn't a global variable an addressable variable?
>
Yes, but if there are no pointers involved, it will never be considered
for aliasing:

int X;

foo()
{
  struct int_float_s x = bar();
  X = 10;
  x.i = 3;
  return X;
}


Diego.

Re: [RFC] ignoring type alias conflicts between structures and scalars

[Richard Kenner]

    But if we just have a structure reference and a global variable, we
    won't ever have this problem.  The aliasing code doesn't look at
    those.  It only ever looks at pointers vs addressable variables.  It
    doesn't care about other variables.

You lost me.  Isn't a global variable an addressable variable?

Re: [RFC] ignoring type alias conflicts between structures and scalars

[Diego Novillo]

On Thu, 2004-11-25 at 13:41 -0700, Jeffrey A Law wrote:

> 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?  But if we just have a structure reference and a global variable,
we won't ever have this problem.  The aliasing code doesn't look at
those.  It only ever looks at pointers vs addressable variables.  It
doesn't care about other variables.

> 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.
> 
Yeah, that was probably it.  If you meant x.y then we will never even
consider x and the global for aliasing.  The problem is when you have x-
>y.  The original code that you sent me had a pointer to a 'struct
basic_block_def' and a global variable of type 'int'.

Too bad this is not well defined in the standard.  We could've gotten a
pretty decent gain if we could ignore these kinds of aliases.


Diego.

Re: [RFC] ignoring type alias conflicts between structures and scalars

[Jeffrey A Law]

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

Re: [RFC] ignoring type alias conflicts between structures and scalars

[Richard Kenner]

    your example is different, in that the int lvalue is not some arbitrary
    pointer dereference, but a known variable.

Yes, I think that's the key.  The alias_sets_conflict_p routine was meant
originally for an RTL environment where every MEM was potentially a pointer
dereference (yes, we knew some of those that weren't, but didn't do much with
that knowlege).  If you want to distinguish between pointers to a type and
variables of that type, you don't have to do the symmetric test.

Re: [RFC] ignoring type alias conflicts between structures and scalars

[Joseph S. Myers]

On Thu, 25 Nov 2004, Nathan Sidwell wrote:

> I don't think Joseph's example of
> 	struct float_int_s {float f; int i;};
>         int i;
>         ((float_int_s *)&((&i)[1]))[-1].i
> 
> being possibly valid is actually valid.  Notice this is forming the address

That wasn't my example :-).  My example was (&(((T*)(char*)&v)->i))[-1] 
(with T being float_int_s and v being i above), where float and int are 
supposed to be the same size with no padding in the structure.

Most cases of pointer conversion, where the pointers are properly aligned, 
are unspecified rather than undefined.  But the resulting pointer still 
has to be a valid pointer (not a trap representation) pointing somewhere 
and given that we document the implementation-defined pointer-integer 
conversions we'd have grave difficulty hooking anything on the conversion 
making a pointer have a different value from the one it started with, as 
opposed to saying that certain *dereferences* are undefined.

For the question of whether &(((T*)(char*)&v)->i) involves undefined 
behavior, you need to know whether an object access is taking place even 
though the address is being taken, which is unclear (the definition of 
unary & has nothing special for structure and union references).  However 
the examples given for flexible array members clearly contemplate being 
able to take their addresses even when the memory for the members isn't 
present, with only subsequent dereferences being undefined.

It is also unclear whether in general an access of a structure or union 
member counts as just one of that member (which might not require the 
whole structure or union to be present) or as one of the whole structure 
or union, but Nick Maclaren's "What is an Object?" (WG14 reflector 9350) 
points out that it must be considered to be just that member to avoid 
rendering such common usages as

    typedef struct {int a; double b; int c;} COMPOSITE;

        COMPOSITE composite = {0,0.0,0};

        composite.a += (composite.c = 0);

undefined by sequence point rules, as they would be if the relevant object 
being modified twice between sequence points were the whole structure.

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
    jsm@polyomino.org.uk (personal mail)
    joseph@codesourcery.com (CodeSourcery mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)

Re: [RFC] ignoring type alias conflicts between structures and scalars

[Richard Kenner]

    So, what I want to teach the alias analyzer is that given a pointer to
    an aggregate type A and a regular variable of a scalar type S, such that
    A and S are not type-compatible, then a pointer to 'A' cannot possibly
    point to a variable of type 'S'.

    So, it boils down to alias_sets_conflict_p being symmetric.  We want to
    consider 'int * -> struct int_float_s' to alias, but we want to reject
    'struct int_float_s * -> int'.

Right.  I think it's just a matter of writing a version of
alias_sets_conflict_p with the second block of code that checks children
removed, leaving just the checks for set 0, the same alias set, and the first
being a subset of the second.  Then call that routine.

It might be worth checking if other places should be using that new routine.
It looks like the usage in gimplify.c and perhaps tree-data-ref.c should as
well.

Re: [RFC] ignoring type alias conflicts between structures and scalars

[Nathan Sidwell]

Diego Novillo wrote:
> Jeff noticed that TBAA was creating some alias relations that don't seem
> to make much sense.  For instance, given

> 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.

> If the program isn't well defined, why is alias_sets_conflict_p() saying
> that 'struct int_float_s' and 'int' have conflicting alias sets?

these conflict because the following program is well formed (typos excepting :)

struct int_s {int i;};

struct int_s thing = {5};

void foo (int *i_ptr, struct int_s *s_ptr)
{
   if (*i_ptr) ...
   *s_ptr = thing;  // could clobber *i_ptr
   if (*i_ptr) ...
}

void baz ()
{
   struct int_s s = {0};
   foo (&s.i, &s);
}

your example is different, in that the int lvalue is not some arbitrary
pointer dereference, but a known variable.

Your example looks to me like the rule about structs with identical initial
field sequences conflict up to the point where the fields diverge, coupled
with the rule that the address of a struct is the address of its first
element (and vice versa).

Thus I think int_float_s conflicts with an int variable, but not a float
variable.

I don't think Joseph's example of
	struct float_int_s {float f; int i;};
         int i;
         ((float_int_s *)&((&i)[1]))[-1].i

being possibly valid is actually valid.  Notice this is forming the address
just past the int variable (valid), casting that to 'float_int_s *' (valid),
indexing -1 struct elements into that (INVALID due to address of start of
struct being outside of i), and then obtaining the i field (valid), which is
where the int is.  If the final two operations are folded together, no
ill-formed address is created, so the construct could be valid. I think that
reasoning is wrong, because it is presuming an optimization that might not
be implemented.

But Joseph has thought about this more than me.

nathan
-- 
Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
nathan@codesourcery.com    ::     http://www.planetfall.pwp.blueyonder.co.uk

Re: [RFC] ignoring type alias conflicts between structures and scalars

[Daniel Berlin]

On Thu, 2004-11-25 at 11:35 -0500, Diego Novillo wrote:
> On Thu, 2004-11-25 at 11:22 -0500, Richard Kenner wrote:
> 
> > If I have two pointers, one to struct_int_float and one to int, it's
> > certainly the case that a store into one can affect what's pointed to by the
> > other and that's what the alias set conflict is trying to address.
> > 
> No, we have one pointer and one regular variable.  I understand that an
> 'int *' may point to a field of 'struct int_float_s'.
> 
> > So what *exactly* are you trying to test?
> > 
> It's in my original message.  Given:
> 
> struct int_float_s {
>    int i;
>    int f;
> };
> 
> int X;
> 
> foo()
> {
>    struct int_float_s *x = bar();
>    X = 10;
>    x->i = 3;
>    return X;
> }
> 
> I don't want to consider 'X = 10' and 'x->i = 3' to be stores to the
> same memory location.  That is, I want the optimizers to assume that
> pointer 'x' cannot possibly be pointing to 'X'.
These two statements are saying  the same thing about two different
types.

(*x).i == int
X == int

Thus, they can alias, AFAIK


*x == struct int_float_s
X == int

Thus, they can't alias.


So while x can't alias with X, it can X can alias with x->i.
AFAIK.


--Dan

PS i like how you named a structure containing only ints "int_float_s"
:)

Re: [RFC] ignoring type alias conflicts between structures and scalars

[Diego Novillo]

On Thu, 2004-11-25 at 11:22 -0500, Richard Kenner wrote:

> If I have two pointers, one to struct_int_float and one to int, it's
> certainly the case that a store into one can affect what's pointed to by the
> other and that's what the alias set conflict is trying to address.
> 
No, we have one pointer and one regular variable.  I understand that an
'int *' may point to a field of 'struct int_float_s'.

> So what *exactly* are you trying to test?
> 
It's in my original message.  Given:

struct int_float_s {
   int i;
   int f;
};

int X;

foo()
{
   struct int_float_s *x = bar();
   X = 10;
   x->i = 3;
   return X;
}

I don't want to consider 'X = 10' and 'x->i = 3' to be stores to the
same memory location.  That is, I want the optimizers to assume that
pointer 'x' cannot possibly be pointing to 'X'.

At the moment, the fact that 'struct int_float_s' conflicts with 'int'
causes us to think that 'x' may point to 'X'.

So, what I want to teach the alias analyzer is that given a pointer to
an aggregate type A and a regular variable of a scalar type S, such that
A and S are not type-compatible, then a pointer to 'A' cannot possibly
point to a variable of type 'S'.

So, it boils down to alias_sets_conflict_p being symmetric.  We want to
consider 'int * -> struct int_float_s' to alias, but we want to reject
'struct int_float_s * -> int'.


Diego.

Re: [RFC] ignoring type alias conflicts between structures and scalars

[Richard Kenner]

    Ah, OK.  So, it would be safe to short-circuit the alias conflict then?

I don't understand the structure of the code well enough to answer that
definitively, but I'm concerned.

alias_sets_conflict_p is only called eight places in the compiler, so I'd
prefer to either modify it or add a new function to give the relation you
want.

But can you state precisely what that relation *is*?

If I have two pointers, one to struct_int_float and one to int, it's
certainly the case that a store into one can affect what's pointed to by the
other and that's what the alias set conflict is trying to address.

So what *exactly* are you trying to test?

    Right, but we don't even warn about it.  

Indeed.

    I'm thinking that I also need a check for -fstrict-aliasing in the patch.

That's another argument for sticking with functions.c in alias.c since
they already take that into account.

    Would it be the same problem if we were dealing with a union instead of
    a structure?  

Yes.  And arrays.

Re: [RFC] ignoring type alias conflicts between structures and scalars

[Andrew Pinski]

On Nov 25, 2004, at 11:02 AM, Diego Novillo wrote:

> On Thu, 2004-11-25 at 10:51 -0500, Richard Kenner wrote:
>
> Right, but we don't even warn about it.  I'm thinking that I also need 
> a
> check for -fstrict-aliasing in the patch.


This would related to PR 13049.

Thanks,
Andrew Pinski

Re: [RFC] ignoring type alias conflicts between structures and scalars

[Daniel Berlin]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1766 bytes --]



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

[-- Attachment #2: Type: TEXT/X-PATCH, Size: 4321 bytes --]

Index: tree-ssa-alias.c







=========================


=========================


=================







RCS file: /cvs/gcc/gcc/gcc/tree-ssa-alias.c,v







retrieving revision 2.56







diff -d -c -p -u -r2.56 tree-ssa-alias.c







--- tree-ssa-alias.c	24 Nov 2004 14:46:23 -0000	2.56







+++ tree-ssa-alias.c	25 Nov 2004 14:26:09 -0000







@@ -928,7 +928,21 @@ compute_flow_insensitive_aliasing (struc







 			 || is_call_clobbered (var);







 	  if (!tag_stored_p && !var_stored_p)







 	    continue;







-	     







+







+	  /* A scalar variable cannot be aliased with a structure if







+	     their types are not compatible.  ???  But then, why would







+	     alias_sets_conflict_p say that their alias sets are in







+	     conflict?  Given a memory tag of type 'struct X { int b;







+	     float a; }' and a variable of type 'int', their alias







+	     sets are considered to conflict, but it doesn't seem







+	     possible that a 'struct X *' may point to the 'int'







+	     variable.  */







+	  if (TREE_CODE (TREE_TYPE (tag)) == RECORD_TYPE







+	      && !AGGREGATE_TYPE_P (TREE_TYPE (var))







+	      && !lang_hooks.types_compatible_p (TREE_TYPE (tag),







+		                                 TREE_TYPE (var)))







+	    continue;







+







 	  if (may_alias_p (p_map->var, p_map->set, var, v_map->set))







 	    {







 	      size_t num_tag_refs, num_var_refs;







\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0

[-- Attachment #3: Type: TEXT/X-CSRC, Size: 3002 bytes --]

struct int_float_s {







    int i;







    float f;







};















int X;















int *ptr_to_X () { return &X; }















foo()







{







  struct int_float_s *x = (struct int_float_s *) ptr_to_X ();







  X = 10;







  x->i = 3;







  return X;







}







\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0


\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0

Re: [RFC] ignoring type alias conflicts between structures and scalars

[Diego Novillo]

On Thu, 2004-11-25 at 10:51 -0500, Richard Kenner wrote:

> A pointer to an
> integer could alias the structure because the integer field is addressable.
> 
Ah, OK.  So, it would be safe to short-circuit the alias conflict then?

> Note that the flag DECL_NONADDRESSABLE_P exists for those languages where
> there is a way to indicate that taking the address of a component of a
> structure is not allowed.  In that case, the two types don't conflict.
> 
>     I'm also attaching a program that breaks this patch.  Basically, it
>     causes 'bar()' to return &X.
> 
> But that breakage is OK because the pointer-punning cast is supposed to be
> incompatible with -fstrict-aliasing.
> 
Right, but we don't even warn about it.  I'm thinking that I also need a
check for -fstrict-aliasing in the patch.

Would it be the same problem if we were dealing with a union instead of
a structure?  


Thanks.  Diego.

Re: [RFC] ignoring type alias conflicts between structures and scalars

[Richard Kenner]

    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.

    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.  

The reason is because the compatible relation is reflexive.  A pointer to an
integer could alias the structure because the integer field is addressable.

Note that the flag DECL_NONADDRESSABLE_P exists for those languages where
there is a way to indicate that taking the address of a component of a
structure is not allowed.  In that case, the two types don't conflict.

    I'm also attaching a program that breaks this patch.  Basically, it
    causes 'bar()' to return &X.

But that breakage is OK because the pointer-punning cast is supposed to be
incompatible with -fstrict-aliasing.

    If the program isn't well defined, why is alias_sets_conflict_p() saying
    that 'struct int_float_s' and 'int' have conflicting alias sets?

As I said above, because a pointer to "int" can conflict with an operation
that references all of int_float_s since the int pointer could be pointing
into an occurence of int_float_s.

[RFC] ignoring type alias conflicts between structures and scalars

[Diego Novillo]

[-- Attachment #1: Type: text/plain, Size: 1997 bytes --]


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.

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.

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'm also attaching a program that breaks this patch.  Basically, it
causes 'bar()' to return &X.  Since we are now considering that X cannot
alias with TMT.0, we would optimize the function to 'return 10'.  The
question is: Is the program well defined?

If the program isn't well defined, why is alias_sets_conflict_p() saying
that 'struct int_float_s' and 'int' have conflicting alias sets?


Thanks.  Diego.

[-- Attachment #2: 20041125-short-circuit-struct-scalar-alias.diff --]
[-- Type: text/x-patch, Size: 1265 bytes --]

Index: tree-ssa-alias.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/tree-ssa-alias.c,v
retrieving revision 2.56
diff -d -c -p -u -r2.56 tree-ssa-alias.c
--- tree-ssa-alias.c	24 Nov 2004 14:46:23 -0000	2.56
+++ tree-ssa-alias.c	25 Nov 2004 14:26:09 -0000
@@ -928,7 +928,21 @@ compute_flow_insensitive_aliasing (struc
 			 || is_call_clobbered (var);
 	  if (!tag_stored_p && !var_stored_p)
 	    continue;
-	     
+
+	  /* A scalar variable cannot be aliased with a structure if
+	     their types are not compatible.  ???  But then, why would
+	     alias_sets_conflict_p say that their alias sets are in
+	     conflict?  Given a memory tag of type 'struct X { int b;
+	     float a; }' and a variable of type 'int', their alias
+	     sets are considered to conflict, but it doesn't seem
+	     possible that a 'struct X *' may point to the 'int'
+	     variable.  */
+	  if (TREE_CODE (TREE_TYPE (tag)) == RECORD_TYPE
+	      && !AGGREGATE_TYPE_P (TREE_TYPE (var))
+	      && !lang_hooks.types_compatible_p (TREE_TYPE (tag),
+		                                 TREE_TYPE (var)))
+	    continue;
+
 	  if (may_alias_p (p_map->var, p_map->set, var, v_map->set))
 	    {
 	      size_t num_tag_refs, num_var_refs;

[-- Attachment #3: b.c --]
[-- Type: text/x-csrc, Size: 196 bytes --]

struct int_float_s {
    int i;
    float f;
};

int X;

int *ptr_to_X () { return &X; }

foo()
{
  struct int_float_s *x = (struct int_float_s *) ptr_to_X ();
  X = 10;
  x->i = 3;
  return X;
}