On 12/2/21 06:45, Martin Liška 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.
wait, what stmt are you asking for? is this on something like:
if (a < 120)
? Then if it doesnt now anything about 'a', you would expect to get
bool varying because the stmt is a true/false
if you want to know the range of A on this, the instead, pick your edge,
and ask ranger for the range of 'a' on the outgoing edge
Now, I guess what you are looking for is the range of a without any
context? Then you'll want to access the GORI engine directly.. try
ranger->gori().outgoing_edge_range_p (irange &r, edge e, tree name,
*get_global_range_query ());
if you ask for 'a' on the true edge, it should give you [0,119] false
edge should give you [120, +INF]
same thing works for switches... pick and edge and it'll give you the
range of NAME on that edge, without any contextual information.
Anderw
PS if you DO want contextual, skip the final argument and it'll go
directly to what ranger knows at this time, without any additional lookups.
Andrew
