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: Another case of DCE deleting live code


On Tue, 2004-11-09 at 17:07, Richard Kenner wrote:

> But then we get into a potential problem in get_tmt_for.  This is
> determining the alias set that a dereference of this pointer would get
> and doing it with:
> 
>   tree tag_type = TREE_TYPE (TREE_TYPE (ptr));
>   HOST_WIDE_INT tag_set = get_alias_set (tag_type);
> 
> I believe this is wrong.  If TYPE_REF_CAN_ALIAS_ALL (TREE_TYPE (ptr)), then
> the alias set should be zero, but only this code can know that.  So I think
> the following should be there (with the corresponding change to the
> gcc_assert at the end of that function).
> 
>   /* If this pointer can alias anything, then the alias set of anything
>      dereferenced by it is zero.  */
>   if (TYPE_REF_CAN_ALIAS_ALL (TREE_TYPE (ptr)))
>     tag_set = 0;
> 
> but Diego disagrees.
> 
Yes.  The tag_set we compute in get_tmt_for must be exactly what
get_alias_set returns.  We use that to determine which pointers get the
same alias set and other checks.  We must always be able to use this
cached value or get_alias_set (TREE_TYPE (TREE_TYPE (ptr))).

What I said is that if you want to use TYPE_REF_CAN_ALIAS_ALL, you use
it inside may_alias_p.  That function is the core predicate of the alias
analyzer.  So, if you are going to override the pure type information,
you do it there:

--- tree-ssa-alias.c    5 Nov 2004 17:20:26 -0000       2.39.2.6
+++ tree-ssa-alias.c    9 Nov 2004 22:55:11 -0000
@@ -1568,6 +1568,11 @@ may_alias_p (tree ptr, HOST_WIDE_INT mem
        }
     }

+  /* If PTR is flagged as a pointer that can alias anything, return
+     true.  */
+  if (TYPE_REF_CAN_ALIAS_ALL (TREE_TYPE (ptr)))
+    return true;
+
   /* If the alias sets don't conflict then MEM cannot alias VAR.  */
   if (!alias_sets_conflict_p (mem_alias_set, var_alias_set))
     {

Having said that.  Why is it that the alias sets for the types

character[1..4]

and

struct X
{
  character x;
};

are not considered to have conflicting alias sets?  That makes little
sense to me.


Diego.


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