search for: forgetmemoizedresult

...ndingCache.empty()) since on a "top call" we could not have hit self recursion yet? Yes, if we reset them before exiting 'IsTopCall'. I wasn't doing that :) > } > > SCEV *S = createSCEV(); > > If(IsTopCall) { > FinalCache.insert(V, S); > forgetMemoizedResults(PendingCache); >> I'm not 100% sure, but I suspect this will not work. >> forgetMemoizedResults will only remove the Value->SCEV mapping for the conservative cases, but in the test case you attached >> getZeroExtendExpr(S) tries to create a *new* SCEV for %conv5 (since I...

...t; we could not have hit self recursion yet? > > > Yes, if we reset them before exiting 'IsTopCall'. I wasn't doing that :) > > >> } >> >> SCEV *S = createSCEV(); >> >> If(IsTopCall) { >> FinalCache.insert(V, S); >> forgetMemoizedResults(PendingCache); > >>> I'm not 100% sure, but I suspect this will not work. >>> forgetMemoizedResults will only remove the Value->SCEV mapping for the conservative cases, but in the test case you attached >>> getZeroExtendExpr(S) tries to create a *new* SCEV for...

...ndingCache.insert(V, getUnknown(V)); Can this be assert(!PessimisticMode && !PendingCache.empty()) since on a "top call" we could not have hit self recursion yet? > } > > SCEV *S = createSCEV(); > > If(IsTopCall) { > FinalCache.insert(V, S); > forgetMemoizedResults(PendingCache); I'm not 100% sure, but I suspect this will not work. forgetMemoizedResults will only remove the Value->SCEV mapping for the conservative cases, but in the test case you attached getZeroExtendExpr(S) tries to create a *new* SCEV for %conv5 (since I suspect the %conv5->mapp...

...ndingCache.empty()) since on a "top call" we could not have hit self recursion yet? Yes, if we reset them before exiting 'IsTopCall'. I wasn't doing that :) > } > > SCEV *S = createSCEV(); > > If(IsTopCall) { > FinalCache.insert(V, S); > forgetMemoizedResults(PendingCache); >> I'm not 100% sure, but I suspect this will not work. >> forgetMemoizedResults will only remove the Value->SCEV mapping for the conservative cases, but in the test case you attached >> getZeroExtendExpr(S) tries to create a *new* SCEV for %conv5 (since I...

...t; we could not have hit self recursion yet? > > > Yes, if we reset them before exiting 'IsTopCall'. I wasn't doing that :) > > >> } >> >> SCEV *S = createSCEV(); >> >> If(IsTopCall) { >> FinalCache.insert(V, S); >> forgetMemoizedResults(PendingCache); > >>> I'm not 100% sure, but I suspect this will not work. >>> forgetMemoizedResults will only remove the Value->SCEV mapping for the conservative cases, but in the test case you attached >>> getZeroExtendExpr(S) tries to create a *new* SCEV for...

...lse) { // Look up in cache using logic described above If (S = getExistingSCEV()) return S; if (IsTopCall) { PessimisticMode = false; PendingCache.clear(); PendingCache.insert(V, getUnknown(V)); } SCEV *S = createSCEV(); If(IsTopCall) { FinalCache.insert(V, S); forgetMemoizedResults(PendingCache); } else if (PessimisticMode) { PendingCache.insert(V, S); } else { FinalCache.insert(V, S); } return S; } Implementation in ScalarEvolution.cpp uses getSCEVImpl() instead of getSCEV(). The idea is that we can conclude accurate result for the topmost call and for v...

...;> >> >> Yes, if we reset them before exiting 'IsTopCall'. I wasn't doing that :) >> >> >>> } >>> >>> SCEV *S = createSCEV(); >>> >>> If(IsTopCall) { >>> FinalCache.insert(V, S); >>> forgetMemoizedResults(PendingCache); >> >>>> I'm not 100% sure, but I suspect this will not work. >>>> forgetMemoizedResults will only remove the Value->SCEV mapping for the conservative cases, but in the test case you attached >>>> getZeroExtendExpr(S) tries to create a...

...positive value just because it has outdated cached ranges. In fact, I don't see any point in having <nsw>/<nuw> for AddRecs if they are not used to prove useful facts about these recs (such as non-negativeness or positiveness). We will only be able to do it if we accidentally call forgetMemoizedResults for all SCEV that depend on that AddRec (which is very unlikely to ever happen in practice). I tried to clean up cache selectively, but in fact it takes full traversal through all cached SCEVs at least to identify the ones that depend on the updated AddRec, and this completely ruins the idea of sa...

Hi, +CC Max, Serguei This looks like a textbook case of why caching is hard. We first call getZeroExtendExpr on %dec, and this call does end up returning an add rec. However, in the process of simplifying the zext, it also calls into isLoopBackedgeGuardedByCond which in turn calls getZeroExtendExpr(%dec) again. However, this second (recursive) time, we don't simplify the zext and cache a

Hi Sanjoy, SCEV is behaving inconsistently when forming SCEV for this zext instruction in the attached test case- %conv5 = zext i32 %dec to i64 If we request a SCEV for the instruction, it returns- (zext i32 {{-1,+,1}<nw><%for.body>,+,-1}<nw><%for.body7> to i64) This can be seen by invoking- $ opt -analyze -scalar-evolution inconsistent-scev-zext.ll But when computing

...positive value just because it has outdated cached ranges. In fact, I don't see any point in having <nsw>/<nuw> for AddRecs if they are not used to prove useful facts about these recs (such as non-negativeness or positiveness). We will only be able to do it if we accidentally call forgetMemoizedResults for all SCEV that depend on that AddRec (which is very unlikely to ever happen in practice). I tried to clean up cache selectively, but in fact it takes full traversal through all cached SCEVs at least to identify the ones that depend on the updated AddRec, and this completely ruins the idea of sa...