[Bug middle-end/69526] ivopts candidate strangeness

["rdapp at linux dot vnet.ibm.com" <gcc-bugzilla at gcc dot gnu dot org>]

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

--- Comment #24 from rdapp at linux dot vnet.ibm.com ---
Created attachment 38775
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38775&action=edit
Updated patch and test, match.pd/VRP

(In reply to amker from comment #23)
> Hmm, not sure if I mis-understood your point.
> I think there is no *overflow* concept for a VR_RANGE (or a variable),
> overflow is always a semantic concept for an (arithmetic) operation.  Take
> below loop as an example:
> 
> unsigned int i;
> for (i = 4; i != 2; i += 2)
>   {
>     //....
>   }
> 
> Variable i has VR_RANGE [0, MAX_VALUE - 1], but it does overflow in the loop.

Yes, a variable by itself cannot overflow, only an operation can. VRP for
example has a function extract_range_from_binary_expr_1 that performs some
overflow checking internally. It does so by comparing the minima and maxima of
the respective ranges from both operands. I assumed an overflow there would
somehow be propagated into the ranges, hence the question how to access the
cast expression in match.pd.

Guess I was thinking too complicated, getting the range of both operands and
checking if their common minimum is smaller than the maximum should suffice for
now.

Attached is the current version of the patch, no regressions on s390x and
x86-64. The test could be made a bit more specific I suppose, currently it
counts the number of "gimple_simplified"s.