Re: [PATCH] PR tree-optimization/100781 - Do not calculate new values when evaluating a debug, statement.

[Andrew MacLeod <amacleod@redhat.com>]

On 6/1/21 3:34 AM, Richard Biener wrote:
> On Tue, Jun 1, 2021 at 3:38 AM Andrew MacLeod via Gcc-patches
> <gcc-patches@gcc.gnu.org> wrote:
>> An ongoing issue  is the the order we evaluate things in can affect
>> decisions along the way. As ranger isn't a fully iterative pass, we can
>> sometimes come up with different results if back edges are processed in
>> different orders.
>>
>> One of the ways this can happen is when the cache is propagating
>> on-entry values for an SSA_NAME. It calculates outgoing edge values and
>> the gori-compute engine can flag ssa-names that were involved in a range
>> calculation that have not yet been initialized.  When the propagation
>> for the original name is done, it goes back and examines the "poor
>> values" and tries to quickly calculate a better range, and if it comes
>> up with one, immediately tries to go back  and update the location/range
>> gori_compute flagged.   This produces better ranges earlier.
>>
>> However, when we do this in different orders, we can get different
>> results.  We were processing the uses on is_gimple_debug statements just
>> like normal uses, and this would sometimes cause a difference in how
>> things were resolved.
>>
>> This patch adds a flag to enable/disable this attempt to look up new
>> values, and when range_of_expr is processing the use on a debug
>> statement, turns it off for the query.  This means the query will never
>> cause a new lookup, and this should resolve all the -fcompare-debug issues.
>>
>> Bootstrapped on x86_64-pc-linux-gnu, with no new regressions. Pushed.
> Please check if such fixes also apply to the GCC 11 branch.
>
> Richard.
>
>
I've checked both testcases against gcc11 release, and neither is an 
issue there.  Much of this was triggered by changes to the export list.  
That said, is there potential for it to surface? The potential is 
probably there.   We'd have to address it differently tho.  For the 
gcc11 release, since we always run in hybrid mode it doesn't really 
matter if ranger looks up ranges for debug statements... EVRP will still 
pick up what we use to get for them.  we could simply disable looking 
for contextual ranges for is_gimple_stmt and simply pick up the best 
known global/on-entry value available..   I can either provide a patch 
for that now, or deal with it if we ever get a PR.  I'm ok either way.

btw, when is the next point release? I added an infrastructure patch to 
trunk (https://gcc.gnu.org/pipermail/gcc-patches/2021-May/569884.html) 
to enable replacing the on-entry cache to deal with memory consumption 
issues like in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100299 .  I 
specifically put it in early before the other changes so that it could 
be directly applied to gcc11 as well, but I need to follow up with one 
of the replacements I have queued up to look at if we are interested in 
fixing this in gcc 11.  I'll bump the priority to try to hit the next 
release if thats the case.

Andrew