This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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



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



























































































































































































































































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;







}
Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]