[Bug tree-optimization/85315] missed range optimisation opportunity for derefences where index must be 0 or otherwise constrained

["amacleod at redhat dot com" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85315

--- Comment #12 from Andrew Macleod <amacleod at redhat dot com> ---
Maybe I'm a little dense.

if we are presuming that  
  &x + (a + b) 
implies a + b == 0, then we also should assume that

  &x + a  implies a == 0

and if we can make those assumptions, then
&x + 1 is garbage because we can assume 1 == 0.

And if a and b are both unsigned, then I guess we can also assume a == b ==
MAX_UINT / 2 ?


Now, if we decided to actually do this...  I see IL:

<bb 2> :
  x.0_1 = x;
  y = x.0_1;
  a.1_2 = a;
  b.2_3 = b;
  _4 = a.1_2 + b.2_3;
  _5 = (long unsigned int) _4;
  _6 = _5 * 4;
  _7 = &y + _6;

The clear implications is that _6 == 0 in this expression?

If we implemented that in the operator_pointer_plus::op1_range routine, and
then were to back substitute, we'd get
(_6)[0,0] = _5 * 4   -> _5 = [0,0]
(_5)[0,0] = (long unsigned int) _4;  -> _4 == [0,0]
(_4)[0,0] = a.1_2 + b.2_3   which gives us nothing additional...  Other than a
potential relationship to track I suppose  a.1_2 == -B.2_3 for signed, but it
would record that _4 is [0,0] when we calculate an outgoing range.

but regardless, its seems that another straightforward place to do this would
be in statement folding?  Isn't the basic assumption:

_7 = &y + _6;
implies _6 is always 0, which would enable us to fold this to
_7 = &y
then _6 is unused and the other statements would ultimately just go away.

So why not make folding simply throw away the "+ _6" part because it is now
being forced to be 0?  We can't really assume that it is [0,0], but then not
use that information to optimize?