> Am 01.09.2026 um 14:53 schrieb Andrew MacLeod <[email protected]>:
>
> I think this PR ends the debate about whether a path_range should become the
> current range_query.
>
> The problem is in tree-ssa-loop-ch.cc. It uses path_range_query to evaluate a
> path, and during a range_of_stmt() call for a statement on that path, the
> path ranger becomes the current range query. While servicing that query, a
> nested query involving a PHI causes SCEV analysis to be invoked. SCEV then
> performs loop analysis using the path ranger as the current query. This use
> to be a query mismatch and we refused to invoke SCEV because it wouldn't
> work right when picking up ranges from the path further down in the loop
> during general analysis.
>
> So. I slightly reworked the current ad-hoc "change the current query"
> mechanism to allow for a small amount of organized push/pop. The current
> query always starts as a global_range_query. Enable/disable_ranger() is
> altered to push/pop a new ranger instance (as has fast_vrp), and
> gimple-range-fold() also temporarily changes to current range-query IFF the
> incoming query is different than the current one.
>
> I added an active_query_compatible_p () method to a range_query, and have it
> return false for any range_query (ie path-ranger) which is not compatible
> with this.
>
> I put all the "smarts" into the push routine. There is a series of 3 PRs:
> 125854, 126814 and now 126942 which combined, demonstrate that the only safe
> course of action is to revert to the global query if there is a mismatch
> which can't be replaced... And this is now what push_range_query () does.
> If the current query is the same as the requested one, it does nothing. If
> the incoming query to be used does not match the current query, AND is not
> compatible to become the current query, it instead pushes the global range
> query.
>
> I submit this for approval because I added a small vector to "struct
> function" which managed the push/pop list, and I wanted to make sure that is
> OK. Its currently set to 5 pointer elements and an unsigned index counter.
> It might be possible to reduce it to 3, but I figured 5 was future proof.
> Im not sure how sensitive the size of struct function is, so wanted to check.
> If anything ever traps the vec size check, we''re doing something wonky that
> is unexpected and needs to be examined. Is a vec of 5 plus a word OK to
> add to struct function?
It is quite sensitive. Since we should never inherit the ranger stack state
between switching the current function (we could assert its empty) can you make
this a global stack instead please?
Richard
> Bootstrapped on x86_64-pc-linux-gnu with no regressions. OK?
>
> Andrew
>
> <0002-Disallow-path-ranger-from-current_range_query.patch>
