search for: getpredicateat

Hi, Is it intentional that LazyValueInfo.getPredicateAt doesn't solve for the value and only takes assumptions into account? getPredicateAt gets lattice value from cache using getValueAt call: LVILatticeVal LazyValueInfoCache::getValueAt(Value *V, Instruction *CxtI) { ... LVILatticeVal Result; mergeAssumeBlockValueConstantRange(V, Result,...

...can tell this without > needing to know anything about Y. Looks like a good idea, but I'm not sure how LazyValueInfo's interface 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 su...

...though. Solution two will not disturb any existing code but we might need to revisit the uses of stripPointerCasts to fix existing bugs. Suggestions welcome! Thanks, Johannes [0] https://reviews.llvm.org/D54956?vs=on&id=175572&whitespace=ignore-most#inline-485807 [1] LazyValueInfo::getPredicateAt() line ~1714, isKnownNull(...) is used after the stripPointerCasts() function might have changed the bit pattern (and thereby the null-ness). -- Johannes Doerfert Researcher Argonne National Laboratory Lemont, IL 60439, USA jdoerfert at anl.gov -------------- next part --------------...

.... 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 even when it can prove the input is in a constant range. I tried removing the local value check in processCmp so that getPredicateAt would called, but that didn't help either. > Best, > - Stefanos > > > Στις Δευ, 6 Απρ 2020 στις 3:10 π.μ., ο/η Craig Topper < > craig.topper at gmail.com> έγραψε: > >> Adding a nuw to the add -8 is incorrect. From the perspective of the >> unsigned math,...

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.