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

Richard Biener richard.guenther@gmail.com
Wed Jun 2 07:29:56 GMT 2021

On Tue, Jun 1, 2021 at 4:24 PM Andrew MacLeod <amacleod@redhat.com> wrote:
> 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.

I think it would be good to robustify the code even w/o a PR.

> 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.

The first point release is usuall about two month from the initial release
which means in about a month and a half.  It would be nice to fix
those issues and the earlier in the release series the better.


> Andrew

More information about the Gcc-patches mailing list