[PATCH] PR tree-optimization/100781 - Do not calculate new values when evaluating a debug, statement.
Tue Jun 1 07:34:52 GMT 2021
On Tue, Jun 1, 2021 at 3:38 AM Andrew MacLeod via Gcc-patches
> 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.
More information about the Gcc-patches