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

[Richard Biener <richard.guenther@gmail.com>]

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.

> Andrew
>