public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* Re:  [RFC] ignoring type alias conflicts between structures and scalars
@ 2004-11-25 16:11 Richard Kenner
  0 siblings, 0 replies; 17+ messages in thread
From: Richard Kenner @ 2004-11-25 16:11 UTC (permalink / raw)
  To: dnovillo; +Cc: gcc

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

^ permalink raw reply	[flat|nested] 17+ messages in thread
* Re: [RFC] ignoring type alias conflicts between structures and scalars
@ 2004-11-25 21:02 Richard Kenner
  2004-11-25 21:17 ` Diego Novillo
  0 siblings, 1 reply; 17+ messages in thread
From: Richard Kenner @ 2004-11-25 21:02 UTC (permalink / raw)
  To: dnovillo; +Cc: gcc

    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?

^ permalink raw reply	[flat|nested] 17+ messages in thread
* Re: [RFC] ignoring type alias conflicts between structures and scalars
@ 2004-11-25 18:03 Richard Kenner
  0 siblings, 0 replies; 17+ messages in thread
From: Richard Kenner @ 2004-11-25 18:03 UTC (permalink / raw)
  To: nathan; +Cc: gcc

    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.

^ permalink raw reply	[flat|nested] 17+ messages in thread
* Re:  [RFC] ignoring type alias conflicts between structures and scalars
@ 2004-11-25 17:48 Richard Kenner
  0 siblings, 0 replies; 17+ messages in thread
From: Richard Kenner @ 2004-11-25 17:48 UTC (permalink / raw)
  To: dnovillo; +Cc: gcc

    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.

^ permalink raw reply	[flat|nested] 17+ messages in thread
* Re:  [RFC] ignoring type alias conflicts between structures and scalars
@ 2004-11-25 16:28 Richard Kenner
  2004-11-25 16:53 ` Diego Novillo
  0 siblings, 1 reply; 17+ messages in thread
From: Richard Kenner @ 2004-11-25 16:28 UTC (permalink / raw)
  To: dnovillo; +Cc: gcc

    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.

^ permalink raw reply	[flat|nested] 17+ messages in thread
* Re:  [RFC] ignoring type alias conflicts between structures and scalars
@ 2004-11-25 16:02 Richard Kenner
  2004-11-25 16:12 ` Diego Novillo
  0 siblings, 1 reply; 17+ messages in thread
From: Richard Kenner @ 2004-11-25 16:02 UTC (permalink / raw)
  To: dnovillo; +Cc: gcc

    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.

^ permalink raw reply	[flat|nested] 17+ messages in thread
* [RFC] ignoring type alias conflicts between structures and scalars
@ 2004-11-25 15:38 Diego Novillo
  2004-11-25 16:18 ` Daniel Berlin
                   ` (2 more replies)
  0 siblings, 3 replies; 17+ messages in thread
From: Diego Novillo @ 2004-11-25 15:38 UTC (permalink / raw)
  To: gcc; +Cc: Jeff Law

[-- 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;
}

^ permalink raw reply	[flat|nested] 17+ messages in thread
end of thread, other threads:[~2004-11-25 21:02 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-11-25 16:11 [RFC] ignoring type alias conflicts between structures and scalars Richard Kenner
  -- strict thread matches above, loose matches on Subject: below --
2004-11-25 21:02 Richard Kenner
2004-11-25 21:17 ` Diego Novillo
2004-11-25 18:03 Richard Kenner
2004-11-25 17:48 Richard Kenner
2004-11-25 16:28 Richard Kenner
2004-11-25 16:53 ` Diego Novillo
2004-11-25 17:39   ` Daniel Berlin
2004-11-25 16:02 Richard Kenner
2004-11-25 16:12 ` Diego Novillo
2004-11-25 16:28   ` Andrew Pinski
2004-11-25 15:38 Diego Novillo
2004-11-25 16:18 ` Daniel Berlin
2004-11-25 17:48 ` Nathan Sidwell
2004-11-25 18:03   ` Joseph S. Myers
2004-11-25 20:55 ` Jeffrey A Law
2004-11-25 20:58   ` Diego Novillo

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).