Re: [PATCH] Fix PR32921, prune virtual operands of memory accesses based on TBAA

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

On 10/22/07, Richard Guenther <rguenther@suse.de> wrote:
> On Mon, 22 Oct 2007, Daniel Berlin wrote:
>
> > On 10/22/07, Diego Novillo <dnovillo@google.com> wrote:
> > > Daniel Berlin wrote:
> > >
> > > > 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.
> > >
> > > So, this patch makes even less sense to me now.  What is really going on
> > > that Richard's patch has any effect at all?  It seems to me that it
> > > shouldn't.  I'm really confused about the whole thing.
> >
> > I await Richard finding out :)
>
> The patch below works now.  But I now see PRE doing appearantly new
> (or different) optimization and ICE during value-numbering of inserted
> storetmps (that have VOPs that are not renamed yet), so for example
> g++.dg/opt/unroll1.C ICEs with
>
> g++.dg/opt/unroll1.C: In function 'int main()':
> g++.dg/opt/unroll1.C:411: internal compiler error: tree check: expected
> ssa_name, have symbol_memory_tag in VN_INFO, at tree-ssa-sccvn.c:253
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <http://gcc.gnu.org/bugs.html> for instructions.
>
> where the stmt it looks at during this value-numbering is
>
> # VUSE <SMT.75> { SMT.75 }
> storetmp.83_166 = *pt_211


PRE only generates storetmps for stores  that already exist in the program.

So there must be a *pt_211=something right around there, and it should
be a vdef of smt.75.
Certainly, you shouldn't be pruning one but not the other.