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, Diego Novillo <dnovillo@google.com> wrote:
> On 10/21/07, Daniel Berlin <dberlin@dberlin.org> wrote:
> > On 10/21/07, Richard Guenther <rguenther@suse.de> wrote:
> > > p.1_2 = { m.b }
> > > m = { ANYTHING }
> > > m.b = { ANYTHING }
> > > D.1187_3 = { }
> > > D.1185_4 = same as D.1187_3
> > >
> > > Pointed-to sets for pointers in test2
> > >
> > > p.1_2, points-to anything
> >
> > This is wrong.
> > I wonder why it says this.
> >
> > Something in find_what_p_points_to is going wrong.
>
>
> Regardless of why in this case we end up with points-to analysis
> thinking it points to anything, what I'm thinking is this: if PTA
> thinks that the pointer points-to anything, wouldn't it make sense to
> fallback to TBAA and conclude that the symbol cannot be in the
> points-to set?
>

We do this already.

> IIUC, Richard's patch does this analysis during VOP pruning.  I think
> that it makes more sense doing it inside PTA directly.  Unless I'm
> misunderstanding the whole problem.

We in fact, do this :)

This is one of the things that we do when filling in the points-to
bitmaps in find_what_p_points_to.


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