Re: [PATCH] Fix IVOPTs problem

[Jeffrey A Law <law at redhat dot com>]

On Thu, 2005-08-11 at 10:44 +0200, Richard Guenther wrote:
> On Wed, 10 Aug 2005, Jeffrey A Law wrote:
> 
> > On Fri, 2005-08-05 at 11:48 +0200, Richard Guenther wrote:
> > > Compiling gcc.c-torture/execute/20010910-1.c with IVOPTs enabled
> > > leads to ssa verification failures because 
> > > tree-ssa-loop-ivopts.c:rewrite_use does not update ssa form
> > > (it calls update_stmt but misses mark_new_vars_to_rename).
> > But are the transformations performed by ivopts supposed to
> > be changing the aliasing information?
> 
> I don't really know - but appearantly they do.
But do you understand that it's critical to know the answer to
this question?



> Yes, you need the following patch, which enables us to do
> structure decomposition for aliasing in salias for structures
> containing arrays (which was not allowed precisely because of
> problems with IVOPTs and the like - Danny can probably tell
> more).  I.e. it would enable salias for GCCs tree structure, f.i.
Excellent.  Thanks.

We're basically changing a statement like this (after simplifying
20010910-1.c):

  #   VUSE <SFT.1_8>;
  D.1295_5 = ep.rx_skbuff[i_10];

SFT.1_8 is specific to the rx_skbuff field of this structure.

rewrite_use turns it into:

  #   VUSE <SFT.1_8>;
  #   VUSE <SFT.2>;
  D.1295_5 = MEM[base: ep.37_13, index: D.1339_14, step: 4B];

Note the addition of SFT.2, which represents the rx_ring field within 
the structure.  This represents a *loss* of precision in the aliasing
information carried for this statement.  There's no way this statement
will touch rx_ring.

[ It's important to note that the index (D.1339_14) will range from
  1..5 inclusive.  Excluding zero means this loop never looks at
  rx_ring. ]

What's effectively happening is we've turned structure+array access
into pointer arithmetic from an aliased base address.

I don't know our aliasing code well enough if there's a way to avoid
the loss in precision when we transform the structure + array access
into pointer arithmetic.  Perhaps the last field in the TARGET_MEM_REF
node can be used to provide this information.

Can you ping the aliasing gurus to get their opinions?  This is the
critical question we need to answer.


jeff