[PATCH] Fix flow-insensitive alias computation

[Daniel Berlin]

On Thu, Apr 17, 2008 at 11:48 AM, Richard Guenther <rguenther@suse.de> wrote:
>
>  Currently for
>
>  struct Data {
>   double *data;
>   long stride;
>  };
>  struct Foo {
>   double x;
>   struct Data **data;
>   long offset;
>  };
>  void foo (struct Foo *this, int n)
>  {
>   int i;
>   for (i = 0; i < n; ++i)
>     {
>       /* double x = this->x;   <-- dead stmt! */
>       long offset = this->offset;
>       struct Data *d = this->data[offset];
>       double *data = d->data;
>       int stride = d->stride;
>       data[i*stride] = 0.0;
>     }
>  }
>
>  we create dependent on the presence of the marked dead stmt (which isn't
>  there at the time we compute aliasing, but it's presence changes UIDs
>  and ordering of SMTs) a different number of NMTs and in one case
>  have the store data[i*stride] = 0.0 alias both the SMTs for double
>  and for struct Foo and in one case alias only the SMT for double.
>
>  While aliasing the SMT for double alone is enough this difference
>  highlights a bug in compute_flow_insensitive_aliasing which walks
>  over all SMTs like
>
>   for (i = 0; i < ai->num_pointers; i++)
>     {
>  ...
>       tree tag1 = symbol_mem_tag (p_map1->var);
>  ...
>       for (j = i + 1; j < ai->num_pointers; j++)
>         {
>  ...
>           tree tag2 = symbol_mem_tag (p_map2->var);
>  ...
>           /* If the pointers may not point to each other, do nothing.  */
>           if (!may_alias_p (p_map1->var, p_map1->set, tag2, p_map2->set,
>  true))
>             continue;
>  ...
>               add_may_alias (tag1, tag2);
>
>  which if the SMT for 'double' is last in the outer loop this SMT
>  doesn't get any further aliases added, but if it happens to be
>  before the SMT for struct Foo is processed then it will have
>  the SMT for struct Foo added.
>
>  Eventually
>
>           if (may_aliases2 && !bitmap_empty_p (may_aliases2))
>             {
>               union_alias_set_into (tag1, may_aliases2);
>             }

Errr, this was not added at some point to fix anything, AFAIK. The
code there was simply transformed from a loop over the aliases into a
bitmap or :)