PATCH Re: [ast-optimizer-branch] gcc.dg/struct-alias-1.c failure

[Diego Novillo]

On Wed, 12 Jun 2002, Jason Merrill wrote:

> Also, it's not cprop that's getting confused, it's alias analysis.  In the
> unsimplified code, the backend can see that the second store is to a
> different member of s, so it won't conflict with the store we already saw;
> in the simplified code, the struct member reference has been factored out,
> so the alias analysis code doesn't see it.
> 
Indeed.  If alias analysis had worked, cprop would've eliminated
the if().  Switching the two assignments to 's' "fix" the
problem.

> This is exactly what rth was talking about; he argues that we shouldn't
> separate the array and member references.  Until alias analysis improves, I
> think I agree.  I've attached a patch.  In this patch I've commented out
> the code for handling arrays and structs separately, as we might want to
> switch back once alias analysis is more clever.
> 
I agree.  Note that you'll have a few conflicts because your
patch still contains the folding markers.

> In the array simplification function, you made an effort to simplify the
> bounds in left-to-right order.  Why?  It would seem more efficient to
>
To maintain current behaviour.  While I think that there are no
sequence points within an array expression (at least Annex C
doesn't mention any), the following snippet of code will assign
26.02 to a[5][6][7]:

  a[i=5][j=i+1][k=j+1] = 26.02;

If you were to simplify from right to left, you would get:

  k=j+1;
  j=i+1;
  i=5;
  a[i][j][k] = 26.02;

which assigns to a random location of the array.  It might well
be that the code is undefined anyway, but I'd rather preserve
current behaviour.

Of course, we could have an additional argument to add_tree that
tells it whether we want to add to the head or the tail of the
list.

Diego.