search for: forgetloop

...gt; I tracked down a bug in indvars where we weren't updating SCEV properly. > The attached patch shows the fix to this bug with a testcase, but it also > causes five new test failures. > > Indvars isn't restructuring the loop there, so it ideally shouldn't > need to call forgetLoop(). Hmm? It certainly is, it's changing the condition on the branch instruction that makes up the loop latch! Offhand, is it possible that the problem > here is the same as the one in PR8037? > No, that only shows up when you try to run "opt -analyze -indvars -scalar-evolution&quo...

...t; > > I tracked down a bug in indvars where we weren't updating SCEV properly. The attached patch shows the fix to this bug with a testcase, but it also causes five new test failures. > > Indvars isn't restructuring the loop there, so it ideally shouldn't > need to call forgetLoop(). > > Hmm? It certainly is, it's changing the condition on the branch instruction that makes up the loop latch! > > Offhand, is it possible that the problem > here is the same as the one in PR8037? > > No, that only shows up when you try to run "opt -analyze -indva...

...own a bug in indvars where we weren't updating SCEV > properly. The attached patch shows the fix to this bug with a testcase, but > it also causes five new test failures. > > > > Indvars isn't restructuring the loop there, so it ideally shouldn't > > need to call forgetLoop(). > > > > Hmm? It certainly is, it's changing the condition on the branch > instruction that makes up the loop latch! > > > > Offhand, is it possible that the problem > > here is the same as the one in PR8037? > > > > No, that only shows up when you...

...wrote: > Hi, > > I tracked down a bug in indvars where we weren't updating SCEV properly. The attached patch shows the fix to this bug with a testcase, but it also causes five new test failures. Indvars isn't restructuring the loop there, so it ideally shouldn't need to call forgetLoop(). Offhand, is it possible that the problem here is the same as the one in PR8037? > > Would someone be willing to take a look at the failures and figure out why we're getting worse output once this patch is applied? If I had to hazard a guess, I'd say that indvars is probably emitt...

Hi, I tracked down a bug in indvars where we weren't updating SCEV properly. The attached patch shows the fix to this bug with a testcase, but it also causes five new test failures. Would someone be willing to take a look at the failures and figure out why we're getting worse output once this patch is applied? If I had to hazard a guess, I'd say that indvars is probably emitting code

...te that your pass preserves ScalarEvolution. In this case all analysis results are by default preserved and it is your job to invalidate the scalar evolution for the loops/values where it needs to be recalculated. The relevant functions are ScalarEvolution::forgetValue(Value *) ScalarEvolution::forgetLoop(Loop *) Cheers Tobi

...g" though -- if you simplified a loop in a way that SCEV can compute its trip count when it couldn't before (or it could compute a trip count before, but now it can compute a more precise trip count) then invalidating the cache can be an improvement. However, in this case judicious use of forgetLoop() (as opposed to re-constructing the whole of SCEV) will also do the job. -- Sanjoy >> I would be okay if you wanted to expose those tricks via a helper in >> SCEV that could be called independently of creating zero or sign >> extensions. That way SCEV clients could trade-off c...

...a loop in a way that SCEV can compute its trip count when >> it couldn't before (or it could compute a trip count before, but now >> it can compute a more precise trip count) then invalidating the cache >> can be an improvement. However, in this case judicious use of >> forgetLoop() (as opposed to re-constructing the whole of SCEV) will >> also do the job. > > In this particular case, neither of the passes that I'm marking as newly > preserving SCEV modify any loop structure or any instructions that should > impact any of the existing SCEV values. All...

On Thu, 2011-11-10 at 23:07 +0100, Tobias Grosser wrote: > On 11/08/2011 11:29 PM, Hal Finkel wrote: > > On Tue, 2011-11-08 at 20:24 +0100, Tobias Grosser wrote: > >> On 11/08/2011 03:36 PM, Hal Finkel wrote: > >>> On Tue, 2011-11-08 at 12:12 +0100, Tobias Grosser wrote: > >>>> On 11/08/2011 11:45 AM, Hal Finkel wrote: > > [A lot of performance

Hi, On Tue, Aug 8, 2017 at 12:58 PM, Friedman, Eli <efriedma at codeaurora.org> wrote: > Oh, I see... yes, we do stupid things involving mutating NoWrap flags after > a SCEV is created. (grep for setNoWrapFlags in ScalarEvolution.cpp.) That's really a compile time hack -- we defer some expensive tricks to prove nsw/nuw on an add recurrences to when we've been asked to

On Nov 5, 2013, at 11:42 AM, Renato Golin <renato.golin at linaro.org> wrote: > On 2 November 2013 05:59, Hal Finkel <hfinkel at anl.gov> wrote: > > I would be scared to enable SCEV AA because it's not well tested > > This seems like a solvable problem. SCEV AA itself is something like 30 lines of non-boilerplate code, and essentially does one thing (calls

...e two load pointers once I know that they share the same base. And once I do that, how do I get the offset (if known). I see the get[Uns|S]ignedRange functions, but if there is a way to directly get a constant value, then that would be more straightforward. Thanks again, Hal > ScalarEvolution::forgetLoop(Loop *) > > Cheers > Tobi -- Hal Finkel Postdoctoral Appointee Leadership Computing Facility Argonne National Laboratory

On 11/08/2011 11:29 PM, Hal Finkel wrote: > On Tue, 2011-11-08 at 20:24 +0100, Tobias Grosser wrote: >> On 11/08/2011 03:36 PM, Hal Finkel wrote: >>> On Tue, 2011-11-08 at 12:12 +0100, Tobias Grosser wrote: >>>> On 11/08/2011 11:45 AM, Hal Finkel wrote: [A lot of performance results skipped] OK. As expected part of the speedup is because of unrolling, however it