On Wed, May 11, 2016 at 7:56 PM, Marc Glisse <marc.gli...@inria.fr> wrote: > On Wed, 11 May 2016, Jeff Law wrote: > >>> We could also simplify (int)(_Bool)x to x using VRP information that x >>> is in [0, 1], but apparently when VRP replaces x==0 with y=x^1,(_Bool)y, >>> it does not compute a range for the new variable y, and by the time the >>> next VRP pass comes, it is too late. >> >> Seems like a clear oversight. > > > In get_value_range, there is: > /* If we query the range for a new SSA name return an unmodifiable > VARYING. > We should get here at most from the substitute-and-fold stage which > will never try to change values. */ > so this is a known limitation. > > We could try to change that (XRESIZEVEC, memset(0) on the new elements, > update num_vr_values to the new num_ssa_names, at this point vr_value should > be replaced with a vector). > > We could also use set_range_info and make simplify_conversion_using_ranges > use get_range_info instead of get_value_range. Might even move the whole > function to match.pd then ;-)
Yeah - note that VRP already calls set_range_info before simplifying stmts. It's just that substitute_and_fold doesn't apply fold_stmt (and thus match.pd) to all stmts but it only applies the pass specific "fold" (vrp_fold_stmt) to all stmts. Richard. > -- > Marc Glisse
