search for: pr2857

...t enough to get itself into trouble on this test. > > Unfortunately, I'm not familiar enough with SCEV and SCEVExpander specifically > to know how to bypass binomial coefficient expansion. What should happen in > SCEVExpander::visitAddRecExpr to avoid it? Take a look at llvm.org/PR2857. Did the patch there make it into LLVM 2.4 or no? Nick > Thanks. > > -Dave > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.c...

...n > > this test. > > > > Unfortunately, I'm not familiar enough with SCEV and SCEVExpander > > specifically to know how to bypass binomial coefficient expansion. What > > should happen in SCEVExpander::visitAddRecExpr to avoid it? > > Take a look at llvm.org/PR2857. Did the patch there make it into LLVM > 2.4 or no? Yes, I think so. I think what's happening is that our optimizer is giving LLVM something it's never seen before. It turns out I "fixed" the problem by reverting to LLVM 2.3 behavior and truncating the calculations to 64 b...

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