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.
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.
Thanks for help,
Martin
Richard.
Martin
Andrew
