This is the mail archive of the 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 Sat, 20 Oct 2007, Diego Novillo wrote:

> On 10/18/07, Daniel Berlin <> wrote:
> > > So the following is bootstrapping & testing now.
> > > 2007-10-18  Richard Guenther  <>
> > >
> > >         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

> 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(!) and so we cannot prune the points-to
set by TBAA in any useful manner for disambiguating structure member
accesses.  If we don't end up using SFTs for the structure members
then the offset based pruning doesn't help us either - but trivially
TBAA pruning can certainly help here.

But once I'll have a working patch, I'll try to gather some numbers
on the amount of pruning done.


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