search for: isimpliedcondoperands

...ducing some way to use these invariants. I think that a natural place is to integrate these is with ScalarEvolution. We'd want functions like getUnsignedRange, isKnownNegative, isKnownPredicate, etc. to automatically take advantage of declared invariants. Internally, SE uses a function: /// isImpliedCondOperands - Test whether the condition described by Pred, /// LHS, and RHS is true whenever the condition described by Pred, FoundLHS, /// and FoundRHS is true. bool isImpliedCondOperands(ICmpInst::Predicate Pred, const SCEV *LHS, const SCEV *RHS,...

...+7] * 2; } I think it will be sufficient to add a couple of new cases to ScalarEvolution::HowManyLessThans -- zext(A) ult zext(B) == A ult B sext(A) slt sext(B) == A slt B Currently it bails out if it sees a non-add recurrence on the LHS of the ult/slt. You could also teach ScalarEvolution::isImpliedCondOperands the following: zext(A) ult zext(B) <=> A ult B sext(A) slt sext(B) <=> A slt B to get more aggressive promotion from ext{A,+,B} to {ext A,+,ext B}. I'll be happy to review these patches. -- Sanjoy

Hi, This is somewhat similar to the previous thread regarding missed vectorization opportunities (http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-April/084765.html), but maybe different enough to require a new thread. I'm seeing some missed vectorization opportunities in the loop vectorizer because SCEV is not able to fold sext/zext expressions into recurrence expressions (AddRecExpr). This