search for: processcmp

...ap, 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 getConstant doesn't handle icmp ev...

...foo(); if (n1 == n2) { return false; // unreachable } } return true; } In this case, simplifycfg doesn't go wild merging everything into a single branch-free expression and so we don't get it. CorrelatedValuePropagation doesn't get this because its processCmp is quite weak (it bails out if one operand isn't a constant). JumpThreading is the only other pass that uses LazyValueInfo and it can't fold this since it can't thread a jump around the side-effecting `foo()` call. I'm not familiar with GVN but it doesn't seem to help for this...

...} >> } >> return true; >> } >> >> In this case, simplifycfg doesn't go wild merging everything into a >> single branch-free expression and so we don't get it. >> >> >> CorrelatedValuePropagation doesn't get this because its processCmp is >> quite weak (it bails out if one operand isn't a constant). JumpThreading is >> the only other pass that uses LazyValueInfo and it can't fold this since it >> can't thread a jump around the side-effecting `foo()` call. >> >> I'm not familiar with G...

...return true; >>> } >>> >>> In this case, simplifycfg doesn't go wild merging everything into a >>> single branch-free expression and so we don't get it. >>> >>> >>> CorrelatedValuePropagation doesn't get this because its processCmp is >>> quite weak (it bails out if one operand isn't a constant). JumpThreading is >>> the only other pass that uses LazyValueInfo and it can't fold this since it >>> can't thread a jump around the side-effecting `foo()` call. >>> >>> I'm...

...rn false; // unreachable > } > } > return true; > } > > In this case, simplifycfg doesn't go wild merging everything into a single > branch-free expression and so we don't get it. > > > CorrelatedValuePropagation doesn't get this because its processCmp is > quite weak (it bails out if one operand isn't a constant). JumpThreading is > the only other pass that uses LazyValueInfo and it can't fold this since it > can't thread a jump around the side-effecting `foo()` call. > > I'm not familiar with GVN but it doesn'...

...;> } >>>> >>>> In this case, simplifycfg doesn't go wild merging everything into a >>>> single branch-free expression and so we don't get it. >>>> >>>> >>>> CorrelatedValuePropagation doesn't get this because its processCmp is >>>> quite weak (it bails out if one operand isn't a constant). JumpThreading is >>>> the only other pass that uses LazyValueInfo and it can't fold this since it >>>> can't thread a jump around the side-effecting `foo()` call. >>>> >...

On Thu, Jun 30, 2016 at 6:09 PM, Carlos Liam via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi all, > > Consider this C code: > > #include <stdbool.h> > > bool func(int n1, int n2, bool b) { > bool greater = n1 > n2; > if (greater && b) { > if (n1 == n2) { > return false; // unreachable > } >

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 all, Consider this C code: #include <stdbool.h> bool func(int n1, int n2, bool b) { bool greater = n1 > n2; if (greater && b) { if (n1 == n2) { return false; // unreachable } } return true; } The line marked unreachable cannot be reached, however currently LLVM does not optimize it out. I believe this is because LLVM does not