Re: [PATCH] Fix inconsistent pruning of aliases

["Daniel Berlin" <dberlin at dberlin dot org>]

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


> >
> > [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.
> 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.