On Thu, Dec 2, 2021 at 2:10 PM Martin Liška <mli...@suse.cz> wrote: > > On 12/2/21 13:01, Richard Biener wrote: > > On Thu, Dec 2, 2021 at 12:45 PM Martin Liška <mli...@suse.cz> wrote: > >> > >> On 12/1/21 19:21, Andrew MacLeod wrote: > >>> On 12/1/21 09:48, Martin Liška wrote: > >>>> On 12/1/21 15:34, Richard Biener wrote: > >>>>> On Wed, Dec 1, 2021 at 3:25 PM Martin Liška <mli...@suse.cz> wrote: > >>>>>> > >>>>>> On 12/1/21 15:19, Richard Biener wrote: > >>>>>>> which is compute the range of 'lhs' on edge_true into > >>>>>>> predicate->true_range, > >>>>>>> assign that same range to ->false_range and then invert it to get the > >>>>>>> range on the false_edge. What I am saying is that for better > >>>>>>> precision > >>>>>>> you should do > >>>>>>> > >>>>>>> ranger->range_on_edge (predicate->false_range, edge_false, > >>>>>>> lhs); > >>>>>>> > >>>>>>> rather than prematurely optimize this to the inversion of the true > >>>>>>> range > >>>>>>> since yes, ranger is CFG sensitive and only the_last_ predicate on a > >>>>>>> long CFG path is actually inverted. > >>>>>>> > >>>>>>> What am I missing? > >>>>>> > >>>>>> I might be misunderstood, but I think it's the problem defined here: > >>>>>> https://gcc.gnu.org/pipermail/gcc-patches/2021-November/584605.html > >>>>>> > >>>>>> where I used the ranger->range_on_edge on the false_edge. > >>>>> > >>>>> Ah, OK. But then even the true_edge range is possibly wrong, no? > >>>> > >>>> You are of course correct, I've just proved that in debugger :// > >>>> > >>>>> Consider > >>>>> > >>>>> for (;;) > >>>>> { > >>>>> if (a < 100) > >>>>> if (a > 50) // unswitch on this > >>>>> /* .. */ > >>>>> if (a < 120) > >>>>> /* ... */ > >>>>> } > >>>>> > >>>>> then you record [51, 99] for true_range of the a > 50 predicate and thus > >>>>> simplification will simplify the if (a < 120) check, no? > >>>> > >>>> Yep. > >>>> > >>>>> > >>>>> You can only record the range from the (CFG independent) a > 50 check, > >>>>> thus [51, +INF] but of course at simplification time you can also use > >>>>> the CFG context at each simplification location. > >>>> > >>>> @Andrew: How can I easily get irange based just on a stmt? Something > >>>> like fold_range > >>>> with int_range_max as the 3rd argument? > >>>> > >>> Sorry, I miss these things if I'm not directly CC'd a lot :-) > >>> > >>> So you just want to know the basic range the stmt generates without > >>> context? Sure, what you say would be fine, but your want to initialize > >>> it to the type range: > >> > >> Yes, I want to know range of LHS in a gcond statement and the same for > >> cases in a gswitch statement. > >> > >>> > >>> int_range_max range (TREE_TYPE (name)); > >>> > >>> you can also simply trigger it using the current SSA_NAME_RANGE_INFO > >>> global values query instead of the default current contextual one... > >>> which , if there isnt a global range, will automatically use the range of > >>> the type of the argument.. so maybe just try > >>> > >>> fold_range (r, stmt, get_global_range_query ()) > >> > >> Doing > >> > >> predicate->true_range = int_range_max (TREE_TYPE (lhs)); > >> fold_range (predicate->true_range, stmt, get_global_range_query > >> ()); > >> predicate->true_range.debug(); > >> > >> gives me _Bool VARYING. > > > > Likely because that gives a range for the bool result rather than > > a range for the LHS of a LHS op RHS on the true or false edge. > > Yes :) I guess Andrew can help us.
some grepping and poking found be gimple_range_calc_op1 which should eventually do the trick (for constant gimple_cond_rhs at least). > > I would guess no stmt level API gives that. In previous VRP > > incarnation assert expr discovery would yield the asserts > > that hold for the LHS on the respective edge and from the asserts > > ranges could be determined. > > About the gswitch statements, I need similarly irange for a switch statement > on an edge e. Well, you simply want a range (and condition to generate the if from) from a CASE_LABEL_EXPR. Given that's either a single integer constant or a RANGE_EXPR it should be easy to use some of the irange CTORs here. Richard. > Thanks for help, > Martin > > > > > Richard. > > > >> > >> Martin > >> > >>> > >>> Andrew > >>> > >>> > >>> > >>> > >> >
