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 >
