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/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?

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.


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