This is the mail archive of the gcc-patches@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: [PATCH] Fix PR32921, prune virtual operands of memory accesses based on TBAA


On 10/21/07, Richard Guenther <rguenther@suse.de> wrote:
> On Sat, 20 Oct 2007, Diego Novillo wrote:
>
> > On 10/18/07, Daniel Berlin <dberlin@dberlin.org> wrote:
> >
> > > > So the following is bootstrapping & testing now.
> > > > 2007-10-18  Richard Guenther  <rguenther@suse.de>
> > > >
> > > >         PR middle-end/32921
> > > >         * tree-ssa-operands.c (access_can_touch_variable): Aliases
> > > >         with non-conflicting alias sets with the reference do not
> > > >         touch the access.  Re-structure function a bit.
> > > >
> > > >         * gfortran.dg/pr32921.f: New testcase.
> > > >         * gcc.c-torture/execute/20071018-1.c: Likewise.
> > >
> > > This looks fine to me.
> >
> > I don't follow.  Why would we need to use TBAA information during
> > pruning?  Pruning is used to remove conflicts that points-to or TBAA
> > couldn't.  It uses location-specific information for each memory
> > reference.
> >
> > So, if a symbol X is in an alias set, it is because TBAA found it to
> > be type-compatible with the pointed-to type for the base pointer P.
> > Or because points-to analysis found P pointing to X.
>
> (*)
>
> > If we are dealing with the first case, then pruning using TBAA is
> > clearly superfluous because X will not be in the alias set to begin
> > with.
> >
> > The one case where I may believe this could happen is if X is in the
> > alias set because points-to conservatively gave up and was forced to
> > assume that P points-to X.  Is this the case that you are handling
> > here Richard?
>
> Maybe this is what is left now. The case that was relevant for fixing
> PR32921 was that we had an access like (*A)[i] where the base pointer (*)
> had alias set zero, but the memory access some other non-conflicting
> alias set.  But since then I noticed this and fixed this particular
> problem.
>
> > But if you are *only* using the fact that X and *P are not conflicting
> > using TBAA, then this should've been handled by points-to earlier.
> > So, X shouldn't have finished in *P's alias set.  Otherwise, I think
> > this approach is buggy.
>
> No, I'm using the fact that at a memory reference location the access
> to *P has a type meaningful for TBAA, unlike at PTA analysis (*).  So
> yes, I think what this patch (or it successors) tries to do is to help
> the case where PTA "gave up" or for some reason its result was too
> conservative.  Indeed, once Danny switched PTA to "real PTA", for
>
> struct foo {
>   int a;
>   double x;
> } m;
>
> int *a = &m.x;
>
> PTA says that a points to m(!)

?
It should say it points to m.x in this case.

The only cases where it wil get different answers from where it used
to is when you do things like:


struct foo *a = &m;

Before it would say a points to m and  m.x
Now it just says it points to m.a, and we rely on the offset and size
of the access at operands time to figure out where it is accessing
from the pointed-to pointer.


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