search for: getconstantrang

...empty cache, I guess. >> >> > for (BasicBlock &BB : F) { >> > for (Instruction &I : BB) { >> > if (Value* v = dyn_cast<Value>(&I)) >> > if (v->getType()->isIntegerTy()) { >> > ConstantRange r = LV.getConstantRange(v, &BB, &I); >> > I.dump(); >> > printf("LOWER VALUE : %llu\n",r.getLower().getRawData()); >> > printf("UPPER VALUE : %llu\n",r.getUpper().getRawData()); >> > } >> > } >> >> Abo...

...lazy (hence, LVI), so you're trying to print an empty cache, I guess. > for (BasicBlock &BB : F) { > for (Instruction &I : BB) { > if (Value* v = dyn_cast<Value>(&I)) > if (v->getType()->isIntegerTy()) { > ConstantRange r = LV.getConstantRange(v, &BB, &I); > I.dump(); > printf("LOWER VALUE : %llu\n",r.getLower().getRawData()); > printf("UPPER VALUE : %llu\n",r.getUpper().getRawData()); > } > } About your other question, "the value range pass was not abl...

...hen I said it was guaranteed to wrap, I only meant for the range of values that were possible after the first branch. In theory, the CorrelatedValuePropagation pass should have been able to optimize the select. It was able to see that the input to add was in the range [8,14) in the call to LVI->getConstantRange in processBinOp. processCmp skips calling LVI for the select's icmp because the input isn't in the same basic block and isn't a phi. And the call to LVI->getConstant for the select in processSelect didn't return a constant. I think this is because the code executed for getConsta...

...rface would support this case. Did you mean synthesizing the INT_MAX constant and then checking specifically for "X s< INT_MAX" using LazyValueInfo::getPredicateAt? At a glance that seems like it would work, but it feels like an odd way of doing it. Initially I was looking at LVI::getConstantRange but its "at the end of the specified block" interface seems too restrictive. The block containing the comparison may end in a conditional br and so surely LVI can't prove anything there. And the block containing the increment/decrement instruction may contain some later informati...

Hello, I am trying to figure out, what vrp propagation does in llvm. I tried this program: #include <stdio.h> int main() { int s = 0; int j = 0; for (int i = 0; i < 100; i++) { j = j+i+1; s+=j; } return (s+j); } And got this under optimized version ( I don't want everything to be eliminated) define i32 @main()

Adding a nuw to the add -8 is incorrect. From the perspective of the unsigned math, -8 is treated a very large positive number. The input to the add is [8,13) and adding a large positive number to it wraps around past 0. So that is guaranteed unsigned wrap. On the other hand, a sub nuw 8 would be correct. ~Craig On Sun, Apr 5, 2020 at 3:27 PM Stefanos Baziotis via llvm-dev < llvm-dev at

Hi everyone, I posted some questions related to implementing inference of nsw/nuw flags based on known icmp results to Bug 30428 ( https://llvm.org/bugs/show_bug.cgi?id=30428 ) and it was recommended that I engage a wider audience by coming here. The minimal context is the following, please see the bug report for more detail: > 1. If (X s< Y), then both X + 1 and Y - 1 are nsw. > 2.