search for: istopcall

...urring cycle- getBackedgeTakenInfo(Loop) -> getSCEV(LoopIV) -> getBackedgeTakenInfo(Loop) This is handled correctly because we have some logic to forget loop header phi entries. Under the new setup, we would not have to 'special case' this logic. It will be handled by the same 'IsTopCall' approach. > > ScalarEvolution::getSCEVImpl (Value *V, bool IsTopCall = false) { > // Look up in cache using logic described above > If (S = getExistingSCEV()) > return S; > > if (IsTopCall) { > PessimisticMode = false; > PendingCache.clear(); >...

...> getBackedgeTakenInfo(Loop) -> getSCEV(LoopIV) -> getBackedgeTakenInfo(Loop) > > This is handled correctly because we have some logic to forget loop header phi entries. Under the new setup, we would not have to 'special case' this logic. It will be handled by the same 'IsTopCall' approach. > >> >> ScalarEvolution::getSCEVImpl (Value *V, bool IsTopCall = false) { >> // Look up in cache using logic described above >> If (S = getExistingSCEV()) >> return S; >> >> if (IsTopCall) { >> PessimisticMode = false;...

...urring cycle- getBackedgeTakenInfo(Loop) -> getSCEV(LoopIV) -> getBackedgeTakenInfo(Loop) This is handled correctly because we have some logic to forget loop header phi entries. Under the new setup, we would not have to 'special case' this logic. It will be handled by the same 'IsTopCall' approach. > > ScalarEvolution::getSCEVImpl (Value *V, bool IsTopCall = false) { > // Look up in cache using logic described above > If (S = getExistingSCEV()) > return S; > > if (IsTopCall) { > PessimisticMode = false; > PendingCache.clear(); >...

...> getBackedgeTakenInfo(Loop) -> getSCEV(LoopIV) -> getBackedgeTakenInfo(Loop) > > This is handled correctly because we have some logic to forget loop header phi entries. Under the new setup, we would not have to 'special case' this logic. It will be handled by the same 'IsTopCall' approach. > >> >> ScalarEvolution::getSCEVImpl (Value *V, bool IsTopCall = false) { >> // Look up in cache using logic described above >> If (S = getExistingSCEV()) >> return S; >> >> if (IsTopCall) { >> PessimisticMode = false;...

...nservative result for the value in PendingCache. This would be getUnknown() for getSCEV(). > > So getSCEV() may be implemented something like this- > > ScalarEvolution::getSCEV(Value *V) { > return getSCEVImpl(V, true); > } > > ScalarEvolution::getSCEVImpl (Value *V, bool IsTopCall = false) { > // Look up in cache using logic described above > If (S = getExistingSCEV()) > return S; > > if (IsTopCall) { > PessimisticMode = false; > PendingCache.clear(); > PendingCache.insert(V, getUnknown(V)); Can this be assert(!PessimisticMode &amp...

...etBackedgeTakenInfo(Loop) -> getSCEV(LoopIV) -> getBackedgeTakenInfo(Loop) >> >> This is handled correctly because we have some logic to forget loop header phi entries. Under the new setup, we would not have to 'special case' this logic. It will be handled by the same 'IsTopCall' approach. >> >>> >>> ScalarEvolution::getSCEVImpl (Value *V, bool IsTopCall = false) { >>> // Look up in cache using logic described above >>> If (S = getExistingSCEV()) >>> return S; >>> >>> if (IsTopCall) { >&...

...ly. We start with adding the most conservative result for the value in PendingCache. This would be getUnknown() for getSCEV(). So getSCEV() may be implemented something like this- ScalarEvolution::getSCEV(Value *V) { return getSCEVImpl(V, true); } ScalarEvolution::getSCEVImpl (Value *V, bool IsTopCall = false) { // 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);...

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