On June 18, 2021 11:46:08 PM GMT+02:00, Andrew MacLeod <amacl...@redhat.com> wrote: >I am pleased to say that this patch kills the poor value computations >in >the ranger's cache. > >Its been a bit of a thorn, and is mostly a hack that was applied early >on to enable getting some opportunities that were hard to get >otherwise. > >The more consistent propagation we now do combined with other changes >means I can kill this wart on trunk. It even results in a 1% speedup.. >and should resolve some of the excessive compile time issues causes by >undesirable iteration, including 101014.. for good I hope :-). > >I tried turning off the poor_value computations on the GCC11 branch, >and >we may want to consider doing it there too. In my testsuite, we miss a > >total of 3 cases out of 4700 new ones identified by ranger. For the >stability, I'd suggest we turn off poor_value computations there as >well. This patch rips out all the code, but for GCC11 I'd just change >push_poor_value to always return false, thus never registering any >values. less churn that way. I'll run some tests and post that >separately if you think we should go ahead with it. > >Bootstraps on 86_64-pc-linux-gnu with no regressions. pushed.
Nice. I think we should indeed consider mostly syncing the algorithmic changes with GCC 11 to make maintenance easier, at least up to 11.2. Now, please leave such changes some time to bake on trunk before backporting. Thanks, Richard. >Andrew > >The details: > >The cache is designed to propagate info without creating NEW info. Ie, > >It cannot query new ranges, cannot set global ranges, etc... only the >higher level ranger can do that. This is how we avoid cycles when >iterating.. Ranger says "This set this value to X here" , and the >cache's job is to propagate that info around the CFG as needed, >applying >static GORI outgoing ranges along the way. Only the ranger can >request >/set NEW information. > >There were some cases where back edges were missing key bits of info >that hadn't been created yet. The "poor value" approach was a stop-gap > >measure until things improve. When the cache is trying to propagate a >range, the GORI edge computations sometimes wants a value which is not >available. Under some conditions it is allowed to register this as a >"poor value" and continue propagating. When done, it looks at the poor > >value list, and asks the ranger to "go get a new value for this". If >the ranger finds a better value, then this new value is propagated >around. So its a bit of a cheat from the original design. The ranger >is >still the only new-info creator, but the request is sometimes started >from the cache. This is not desirable, and can lead to some >inconsistencies & inefficiencies. > >As one can imagine. this sometimes causes significant iteration, as in >this testcase. Ie, the new ranger request from the cache triggers >another poor value request, etc etc. Which is why it wasn't designed >to >work that way. Anyway, longer story shorter, I revisited the poor >value >code, and discovered that with the new GORI and fold_using_range rework > >from the past month, dropping the poor value code results in *0* >difference in any of our test cases/suites. Further more, the biggest > >thing that it really enabled was picking up range restrictions imposed >by unvisited statements that were being forced to VARYING. The new >rework allows such statements to simply be folded using the new >global_range_query and even so that bit of info is now easily >captured. >That's the enhancement from the second patch.
