search for: isknownnegative

...his will give ScalarEvolution, ValueTracking, etc. the benefit of analyzing these invariants in normalized form. The next step is introducing 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...

Hello Yes, I agree that the SCEV cannot be simplified. Is my understanding correct that it is passed to a function like "isKnownNegative"? Which could still be able to prove is always true. The delinearisation may be valid, depending on exactly how you define delinearisation (under what conditions it should be giving results). It would be invalid for DA to return a dependency of [0 >] though. The code is perfectly valid fro...

Hello Under the proviso that it's been a while since I looked into any of these things... On 05/15, Bardia Mahjour via llvm-dev wrote: > I also get correct results for my example (for a 64-bit target) if the upper > bounds are changed to unsigned. The reason is simply because clang zero-extends > `m` for address calculations but sign-extends it for the loop upper bound. This >