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.
