On 10/28/25 15:50, Robin Dapp wrote:
I added a chunk to print the range being returned. With your path ranger,
R is [irange] BITMAP_WORD [1, +INF] , which I assuem si the value you are
looking for?
Yes, that's it.
(1)
So I tried taking your path ranger patch, and directly used the ranger
you created for the path ranger, and avoided the path ranger completely:
[..]
- if (query.range_of_expr (r, src)
+ if (ranger.range_on_edge (r, loop_preheader_edge (loop), src)
&& !r.varying_p ()
&& !r.undefined_p ())
{
And I get the same range as the path ranger (on x86_64): [irange]
BITMAP_WORD [1, +INF]
ie
(2) It ceases working if I switch to get_range_query(cfun), probably
because there is no active ranger.
[..]
bool range_nonzero = false;
- gimple_ranger ranger;
- path_range_query query (ranger, path);
- if (query.range_of_expr (r, src)
+ if (get_range_query (cfun)->range_on_edge (r, loop_preheader_edge
(loop), src)
&& !r.varying_p ()
&& !r.undefined_p ())
{
This version (2) gives me VARYING.
(3)
If I add the enable/disable ranger calls in the function, which creates
an active ranger again, it Im back to getting [+1, +INF] for a range:
[..]
Maybe we should just enable_ranger in the pass? But I don't think you
need a path ranger to get that info.
Or am I missing something else?
No, I think that clears things up mostly, thank you.
Regarding the trade-off of path ranger vs an active ranger, it appears that
both Richi and you tend to steer away from a path ranger. Is it that much
heavier than a regular ranger or rather a question of "not the right tool for
the task"?
Mostly its not the right tool. Its designed for the threader where it
wants to explore ranges if we follow a specific path through the CFG..
its tries different paths to see if we can resolve conditions along a
specific path and then thread them wehen we can Creating a path that
is a single edge doesn't buy you anything beyond what range_on_edge will
give you.
It is also heavier weight than a basic ranger is. A path_ranger
requires a normal ranger as input which it uses to pick up ranges on
entry to the path, and then the path following mechanism built on top of
a second ranger so that we can set and reset values as we explore
different paths and not pollute the values outside of the path.
Most requirements for ranges can be satisfied by using enable_ranger()
in a pass. As this becomes more prevalent, I wonder if we should turn
enable_ranger() into a call to make sure that there is an active ranger,
and then let the pass manager disable it on the way out of a pass if it
is active. AS it is now, you have to know if there is a ranger active
or now, and pair up the enable/disable calls.
Richi mentioned that niter doesn't have an active ranger for the part I'm
touching. Then I'd enable it in SCCP and go with a range query.
Let me know if you run into any other issues.
Andrew
