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
