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. 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. Richard. > > Martin > > > > > Andrew > > > > > > > > >
