[Bug middle-end/69526] ivopts candidate strangeness

["rguenther at suse dot de" <gcc-bugzilla at gcc dot gnu dot org>]

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

--- Comment #18 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 7 Jun 2016, rdapp at linux dot vnet.ibm.com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69526
> 
> --- Comment #15 from rdapp at linux dot vnet.ibm.com ---
> Thanks for the suggestions. The omission of the inner op was actually more or
> less on purpose as I intended to capture the
> (convert @inner)
> in order to access @inner's value range as a whole rather than re-calculating
> what VRP already figured out.
> 
> Is there a simple method to access @inner when
> capturing
> (outer_op (convert (inner_op SSA_NAME@0 INTEGER_CST@1)) INTEGER_CST@2))
>                    ^---------------------------------^
>                                  @inner
> or, even-better both, @inner as well as @0 and @1, at the same time? (Apart
> from looking through use stmts)
> 
> In my case VRP determines @0's range as ~[0,0] and @inner's as [0,INT_MAX-1].
> VRP probably canonicalized the anti-range to a normal range and performed other
> simplifications in order to arrive at [0,INT_MAX-1]. If I cannot get @inner's
> VRP info with the capture above, would there be another way to obtain it?
> 
> The TREE_OVERFLOW/const_binop code is copied from the (A +- CST) +- CST -> A +
> CST pattern and the result of const_binop is used in the final simplification.
> The overflow check could of course be done via wi::add/sub but wouldn't I just
> replicate what int_const_binop_1 is doing on top of it when I need the result
> anyway?

int_const_binop_1 is legacy, it is better to avoid building an INTEGER_CST
if you throw away the result due to TREE_OVERFLOW.