search for: scevcouldnotcomput

We've upgraded to llvm 2.4 and we're hitting an assert in SCEV: llvm/include/llvm/Analysis/ScalarEvolutionExpressions.h:669: RetVal llvm::SCEVVisitor<SC, RetVal>::visitCouldNotCompute(llvm::SCEVCouldNotCompute*) [with SC = llvm::SCEVExpander, RetVal = llvm::Value*]: Assertion `0 && "Invalid use of SCEVCouldNotCompute!"' failed. This happens in SCEVExpander::visitAddRecExpr where we drop down to this code: // If this is a chain of recurrences, turn it into a closed form, using...

2011/11/21 Tobias Grosser <tobias at grosser.es>: > On 11/20/2011 04:36 PM, Marcello Maggioni wrote: >> >> Sorry for the noobish question, but what kind of subscripts generate a >> SCEVCouldNotCompute  from the SCEV engine? >> I tried for a while but I wasn't able to trigger that > > Hi Marcello, > > the SCEV returns SCEVCouldNotCompute in case it cannot analyze an expression > or if the analysis would be to complicated. I am currently > not sure if this may actually...

David Greene wrote: > We've upgraded to llvm 2.4 and we're hitting an assert in SCEV: > > llvm/include/llvm/Analysis/ScalarEvolutionExpressions.h:669: RetVal > llvm::SCEVVisitor<SC, > RetVal>::visitCouldNotCompute(llvm::SCEVCouldNotCompute*) [with SC = > llvm::SCEVExpander, RetVal = llvm::Value*]: Assertion `0 && "Invalid use of > SCEVCouldNotCompute!"' failed. > > This happens in SCEVExpander::visitAddRecExpr where we drop down > to this code: > > // If this is a chain of recurrences...

...Nick Lewycky wrote: > David Greene wrote: > > We've upgraded to llvm 2.4 and we're hitting an assert in SCEV: > > > > llvm/include/llvm/Analysis/ScalarEvolutionExpressions.h:669: RetVal > > llvm::SCEVVisitor<SC, > > RetVal>::visitCouldNotCompute(llvm::SCEVCouldNotCompute*) [with SC = > > llvm::SCEVExpander, RetVal = llvm::Value*]: Assertion `0 && "Invalid use > > of SCEVCouldNotCompute!"' failed. > > > > This happens in SCEVExpander::visitAddRecExpr where we drop down > > to this code: > > > > // If...

Sorry for the noobish question, but what kind of subscripts generate a SCEVCouldNotCompute from the SCEV engine? I tried for a while but I wasn't able to trigger that. 2011/11/20 Tobias Grosser <tobias at grosser.es>: > On 11/20/2011 03:01 AM, Marcello Maggioni wrote: >> >> 2011/11/19 Tobias Grosser<tobias at grosser.es>: >>> >>> On 11/...

On 11/20/2011 04:36 PM, Marcello Maggioni wrote: > Sorry for the noobish question, but what kind of subscripts generate a > SCEVCouldNotCompute from the SCEV engine? > I tried for a while but I wasn't able to trigger that Hi Marcello, the SCEV returns SCEVCouldNotCompute in case it cannot analyze an expression or if the analysis would be to complicated. I am currently not sure if this may actually happen when calling getSCEV(),...

On 11/21/2011 12:44 PM, Marcello Maggioni wrote: > 2011/11/21 Tobias Grosser<tobias at grosser.es>: >> On 11/20/2011 04:36 PM, Marcello Maggioni wrote: >>> >>> Sorry for the noobish question, but what kind of subscripts generate a >>> SCEVCouldNotCompute from the SCEV engine? >>> I tried for a while but I wasn't able to trigger that >> >> Hi Marcello, >> >> the SCEV returns SCEVCouldNotCompute in case it cannot analyze an expression >> or if the analysis would be to complicated. I am currently >> n...

Most of my programs contain loops that the LoopDeletion pass is unable to remove. It appears that the following code in LoopDeletion.cpp:152 is the culprit: ScalarEvolution& SE = getAnalysis<ScalarEvolution>(); const SCEV *S = SE.getMaxBackedgeTakenCount(L); if (isa<SCEVCouldNotCompute>(S)) return Changed; So, LoopDeletion thinks my loops might be infinite so it does not delete them - even if they do not write to any of the function return values. Is there a way to flag a loop as non-infinite? Or will I need to create my own modified loop deletion pass that can eli...

...ain loops that the LoopDeletion pass is unable > to remove. It appears that the following code in LoopDeletion.cpp:152 > is the culprit: > > ScalarEvolution& SE = getAnalysis<ScalarEvolution>(); > const SCEV *S = SE.getMaxBackedgeTakenCount(L); > if (isa<SCEVCouldNotCompute>(S)) > return Changed; > > So, LoopDeletion thinks my loops might be infinite so it does not delete > them - even if they do not write to any of the function return values. > Is there a way to flag a loop as non-infinite? Or will I need to create > my own modified loop...

...rolling process hits this code in LoopUnrollRuntime.cpp > > // Only unroll loops with a computable trip count and the trip count > needs > // to be an int value (allowing a pointer type is a TODO item) > const SCEV *BECountSC = SE->getBackedgeTakenCount(L); > if (isa<SCEVCouldNotCompute>(BECountSC) || > !BECountSC->getType()->isIntegerTy()) > return false; > > BECountSC=0xcccccccc and returns false here. > > Based on the comments it looks like I still need a constant loop counter. > Is there a way to unroll with non-constant loop counter as...

...l doesn't unroll. The unrolling process hits this code in LoopUnrollRuntime.cpp // Only unroll loops with a computable trip count and the trip count needs // to be an int value (allowing a pointer type is a TODO item) const SCEV *BECountSC = SE->getBackedgeTakenCount(L); if (isa<SCEVCouldNotCompute>(BECountSC) || !BECountSC->getType()->isIntegerTy()) return false; BECountSC=0xcccccccc and returns false here. Based on the comments it looks like I still need a constant loop counter. Is there a way to unroll with non-constant loop counter as in the example above? Thanks, F...

...contain loops that the LoopDeletion pass is unable > to remove. It appears that the following code in LoopDeletion.cpp:152 > is the culprit: > > ScalarEvolution& SE = getAnalysis<ScalarEvolution>(); > const SCEV *S = SE.getMaxBackedgeTakenCount(L); > if (isa<SCEVCouldNotCompute>(S)) > return Changed; > > So, LoopDeletion thinks my loops might be infinite so it does not delete > them - even if they do not write to any of the function return values. > Is there a way to flag a loop as non-infinite? Or will I need to create > my own modified lo...

...opDeletion pass is unable >> to remove. It appears that the following code in LoopDeletion.cpp:152 >> is the culprit: >> >> ScalarEvolution& SE = getAnalysis<ScalarEvolution>(); >> const SCEV *S = SE.getMaxBackedgeTakenCount(L); >> if (isa<SCEVCouldNotCompute>(S)) >> return Changed; >> >> So, LoopDeletion thinks my loops might be infinite so it does not delete >> them - even if they do not write to any of the function return values. >> Is there a way to flag a loop as non-infinite? Or will I need to create >&gt...

...lt;< Log2_32_Ceil(W + T); // Cray: Truncate to 64 bits. It's what we did with LLVM 2.3 and // while it can create miscompilations in some cases if the // computation happens to overflow, it's no worse than what we did // before. if (CalculationBits > 64) { //return new SCEVCouldNotCompute(); CalculationBits = 64; DEBUG(DOUT << "*** [dag] SEVERE WARNING: SCEV calculation truncated to 64 bits, check for miscompilation! ***\n"); } I have never found a test where this actually causes a problem. And we have tens of thousands of tests. It...

...or (to me) of the SCEV analysis > of the loop bound of the external loop I posted. > When in ScopDetection it gets the SCEV of the external loop bound in > the "isValidLoop()" function with: > const SCEV *LoopCount = SE->getBackedgeTakenCount(L); > > It returns a SCEVCouldNotCompute, but if I change the "if" block > inside the loop from: > if (i+j> 1000) > to: > if (i> 1000) > > that SCEV results valid. > > Later in the ScopInfo pass it crashes analyzing the SCEV of the > comparison expression (in buildConditionSets ) . I...

...t;>> to remove. It appears that the following code in LoopDeletion.cpp:152 >>> is the culprit: >>> >>> ScalarEvolution& SE = getAnalysis<ScalarEvolution>(); >>> const SCEV *S = SE.getMaxBackedgeTakenCount(L); >>> if (isa<SCEVCouldNotCompute>(S)) >>> return Changed; >>> >>> So, LoopDeletion thinks my loops might be infinite so it does not delete >>> them - even if they do not write to any of the function return values. >>> Is there a way to flag a loop as non-infinite? Or will I n...

On 11/20/2011 03:01 AM, Marcello Maggioni wrote: > 2011/11/19 Tobias Grosser<tobias at grosser.es>: >> On 11/18/2011 01:34 PM, Marcello Maggioni wrote: >>> >>> Ok , this is what I believe is the final patch that adds the >>> non-affine accept functionality to Polly, this should have no issues. >>> >>> I added three tests, two in ScopInfo

...ound out a very strange behavior (to me) of the SCEV analysis of the loop bound of the external loop I posted. When in ScopDetection it gets the SCEV of the external loop bound in the "isValidLoop()" function with: const SCEV *LoopCount = SE->getBackedgeTakenCount(L); It returns a SCEVCouldNotCompute, but if I change the "if" block inside the loop from: if (i+j > 1000) to: if (i > 1000) that SCEV results valid. Later in the ScopInfo pass it crashes analyzing the SCEV of the comparison expression (in buildConditionSets ) . It's like if it recognizes that "i&qu...

...eletion pass is unable >> to remove. It appears that the following code in LoopDeletion.cpp:152 >> is the culprit: >> >> ScalarEvolution& SE = getAnalysis<ScalarEvolution>(); >> const SCEV *S = SE.getMaxBackedgeTakenCount(L); >> if (isa<SCEVCouldNotCompute>(S)) >> return Changed; >> >> So, LoopDeletion thinks my loops might be infinite so it does not delete >> them - even if they do not write to any of the function return values. >> Is there a way to flag a loop as non-infinite? Or will I need to create >&g...

I need to be able to detect a well-behaved loop. (i.e one where exp1 assigns a value to an int i, exp2 compares i with a loop constant, exp3 adjusts i by a loop constant, and the inner block has no assignments to i.) I need this because in Sun's Java VM garbage collection only takes place at safepoints, so a potentially unbounded loop must call safepoint() some time. However, safepoints are