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

[Andrew MacLeod]

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.

Andrew

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0004-Do-not-calculate-new-values-when-evaluating-a-debug-.patch
Type: text/x-patch
Size: 4198 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc-patches/attachments/20210531/565d6680/attachment.bin>