> 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"?
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.
--
Regards
Robin
