Re: [PATCH] Fix inconsistent pruning of aliases

[Richard Guenther <rguenther at suse dot de>]

On Tue, 20 Nov 2007, Daniel Berlin wrote:

> On 11/20/07, Richard Guenther <rguenther@suse.de> wrote:
> > On Tue, 20 Nov 2007, Richard Guenther wrote:
> >
> > >
> > > This fixes an inconsistency in alias pruning.  The situation is as
> > > follows.  Consider two pointers, p_1 and p_2, p_1 has a NMT which aliases
> > > a global integer var X and SMT.1, p_2 points to anything (no NMT).
> 
> If it pointed to anything, it would get an NMT with the SMT's aliases
> as it's aliases.
> (Unless we are talking about 4.2 or earlier).
> > >
> > >               /* If we do not know the full reference tree or if the access is
> > >                  unspecified [0, -1], we cannot prune it.  Otherwise try doing
> > >                  so using access_can_touch_variable.  */
> > >               if (full_ref
> > >                 && !(offset == 0 && size == -1)
> > >                   && !access_can_touch_variable (full_ref, al, offset, size))
> > >                 continue;
> > >
> > > the fix is to make the behavior consistent and let access_can_touch_variable
> > > prune also in the case of offset == 0 && size == -1 where it will now
> > > prune the alias to X and cause the SMT itself to be added to the VOPs.
> 
> This is quite wrong for 4.3.  The check was added for indeterminate
> accesses.

I added the check only recently with one of the patches addressing
PR33870.  So I just removed it again because it now causes problems
(I added it as a compile-time optimization not realizing that
access_can_touch_variable does pruning even for indeterminate accesses
and non-SFTs)

> p_2 in your above example should have gotten an NMT with X
> as it's variable, regardless of whether it points-to anything or not.

No, it got pt_anything because it was not de-referenced and as such hit

static void
compute_flow_sensitive_aliasing (struct alias_info *ai)
{
...
  for (i = 0; VEC_iterate (tree, ai->processed_ptrs, i, ptr); i++)
    {
      if (!find_what_p_points_to (ptr))
        set_pt_anything (ptr);

if that should still set a NMT I don't know.

> > > [It looks like one still could construct a case where we point to the SMT
> > > but otoh use SMTs aliases for when we have a pt_anything pointer, which
> > > would result in a missing link between both memory accesses -- don't we
> > > want to add the SMT itself in any case in get_addr_dereference_operands:
> > >
> 
> No.  They should have ended up with the same NMT in the first place.
> The only case you will not get a link is if you have strict aliasing
> on and do alias-violating things.
> That's really the only reason we still bother to add the SMT itself.
> There used to be an assert that made sure we added an alias, but
> people broke it with invalid code.

It's all valid code.

> > What I see with the testcase is that a pointer that was not dereferenced
> > at the point aliasing computed the points-to set (and thus it became
> > pt_anything) became dereferenced as result of propagation.  So we have
> > now no flow-sensitive information left for the memory access and use
> > at one point in the program the SMT and at another the NMT (of a different
> > SSA_NAME of the pointer, which was derefed, both pointers point to the
> > same memory though).
> 
> At this point, you need to recompute aliasing (or move propagation to
> a different point).
> Trying to work around that is not going to work very well, it's not
> what the machinery is meant for.

Uhm, so we need to re-run may_alias after every copy-propagation?

 p_2 = p_1
 *p_2;

because after copy-propagation p_1 will now be dereferenced.

Or we should not "punt" in find_what_p_points_to if ptr is not
dereferenced?

Thanks,
Richard.