On 5/29/24 03:19, Richard Biener wrote:
> On Tue, May 28, 2024 at 8:57 PM Andrew MacLeod<amacleod@redhat.com>  wrote:
>> The original patch causing the PR made  ranger's cache re-entrant to
>> enable SCEV to use the current range_query when called from within ranger..
>>
>> SCEV uses the currently active range query (via get_range_query()) for
>> picking up values.  fold_using_range is the general purpose stmt folder
>> many  components use, and it takes a range_query to use for folding.
>> When propagating values in the cache, we need to ensure no new queries
>> are invoked, and when the cache is propagating and calculating outgoing
>> edges, it switches to a read only range_query which uses what it knows
>> about global values to come up with best result using current state.
>>
>> SCEV is unaware of what the caller is using for a range_query, so when
>> attempting to fold a PHI node, it is re-invoking the current query
>> during propagation which is undesired behavior.   This patch tells
>> fold_using_range to not use SCEV if the range_query being used is not
>> the same as the one SCEV is going to use.
>>
>> Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed.
> Can we dump a hint to an active dump-file if this happens?  I suppose it's
> an unwanted situation, like the pass not setting the active ranger?  Sth
> like
>
>     if (src.query () != get_range_query (cfun)
>         && dump_file)
>      fprintf (dump_file, "Using a range query different from the
> installed one\n");
>
> (or better wording).
>
> Btw, could we install src.query () as the global range query around the
> relevant recursion or is the place around where we'd need to do this
> not so clear-cut?
>
As requested, this patch will issues a message in the listing if we fail 
to execute SCEV under normal usage.

Bootstrapped on x86_64-pc-linux-gnu with no regressions.  Pushed.

Andrew