search for: computeknownbits

I've always found the name ComputeMaskedBits a bit unintuitive, and since r154011 it's even worse because there is no masking going on whatsoever: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20120402/140280.html Is there any appetite for a global rename to ComputeKnownBits? Or any other better names? Thanks, Jay.

...uteMaskedBits a bit unintuitive, and >> since r154011 it's even worse because there is no masking going on >> whatsoever: >> >> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20120402/140280.html >> >> Is there any appetite for a global rename to ComputeKnownBits? Or any >> other better names? > > I like computeKnownBits. Sorry for failing to update the name and > comments with the original change. Oh yeah, the comments. I've updated them first in r208757. I'll prepare a patch to rename ComputeMaskedBits to computeKnownBits. Do I ha...

SelectionDAG's computeKnownBits has no case for ConstantFP, e.g. Known.ones = cast <ConstantFPSDNode>(Op)->getValueAFP ().bitcastToAPInt (); I can't easily override this in target specific code. Can anyone see an issue with submitting the patch to upstream? Suggestions for an in tree target that could trigger this...

Today, InstSimplify calls computeKnownBits to try to fold to a constant ONLY if it can't find any other simplifications for an instruction. I think this means if we are able to find an earlier simplification we are LESS aggressive about creating a constant because we won't even look at known bits. This seems surprising to me. Shou...

That's very good. We're clearly further from head of dev than I realised! Thanks for the link. On 19 Jan 2018 18:53, "Friedman, Eli" <efriedma at codeaurora.org> wrote: On 1/19/2018 4:01 AM, Jon Chesterfield via llvm-dev wrote: > SelectionDAG's computeKnownBits has no case for ConstantFP, e.g. > Known.ones = cast <ConstantFPSDNode>(Op)->getValueAFP ().bitcastToAPInt > (); > This was added in https://reviews.llvm.org/rL316831 . -Eli -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Au...

On the subject of undefined behavior and known bits, as I'm sure some of you are aware, code in ValueTracking.cpp is exploiting poison value rules to get a bit of extra precision in the known bits. These rules fire on examples like the ones below. Do we have a set of rules that clients of known bits need to follow to avoid unsoundness? I remember Nuno and/or David Majnemer saying

...>> From what I can tell LLVM has no facilities to determine from this code that %.x >= 0, so (for example) an SExt on %.x will not be converted to a ZExt. >> >> I'm interested in seeing what sorts of changes would be needed to recognize this pattern in existing facilities (computeKnownBits, etc.) in order to more broadly apply optimizations that use those facilities. > LVI has a couple of special cases around select idioms. This would be another reasonable one to add. This would give range analysis (used in JumpThreading and CVP) for this idiom. I thought we already had this on...

While looking at optimizations where Souper exploits known bits, I realized that it would be easy to teach Souper to compute known bits. Comparing its results against computeKnownBits() from r246393, it looks like there are some easy (and some not-easy) opportunities for improvement, please see a few examples below. The expressions come from compiling LLVM itself. Happily, this exercise didn't identify any errors of unsoundness, only imprecisions. If anyone starts to...

...is effectively max(x, 0). From what I can tell LLVM has no facilities to determine from this code that %.x >= 0, so (for example) an SExt on %.x will not be converted to a ZExt. I'm interested in seeing what sorts of changes would be needed to recognize this pattern in existing facilities (computeKnownBits, etc.) in order to more broadly apply optimizations that use those facilities. Any insight would be appreciated. Thanks!

...insert the mask would fix this, but I agree that someone, > > somewhere needs to put in the mask if we want to allow speculation > > here, and the target can’t do the variable extract in a register. > > I'd rather the frontend do this if the language wants it. We can use > ComputeKnownBits when we do the speculation check, and so if there > is a mask, we'll be fine. > > > > I don't think we can rely on ComputeKnownBits for this sort of thing. > Consider: > %and = and i64 %x, 1 > %idx = lshr exact i64 %and, 1 > %z = extractelement <4 x i32>...

...ly. I'd like to take a look at the other side of the equation: the cost of adding a new intrinsic in terms of teaching passes to see through it, so we don't lose optimizations that worked before the intrinsic was added. For example, clearly ValueTracking needs a few lines added so that computeKnownBits and friends don't get stopped by a rotate. Anyone have a reasonably complete list of files that need similar changes? John

...nce.  (If you want a full review, please post > on Phabricator.) +1 In your example, we have: 3 - idx == idx => 3 == 2*idx and you've generalized this slightly to make this: (odd number) == 2*idx which makes sense. I think that we can go further looking at: n == 2*idx and, calling computeKnownBits on n and idx, then asking whether: knownZeros(n) == (knownZeros(idx) << 1) | 1 and knownOnes(n) == knownOnes(idx) << 1 (please note the comment in aliasSameBasePointerGEPs regarding avoiding PR32314) also, if we have more than one array access, we can have: n - idx == m - idx then...

...h ~20% originates from CGPassManager. >> > > It's because we run instcombine as we inline (see > addFunctionSimplificationPasses()) IIRC. We don't quite do this at LTO > time (FullLTO) because it's too expensive compile-time wise. ThinLTO > runs it. > >> ComputeKnownBits contributes 7.8%, but calls from InstCombine contribute only 2.6% to the total execution time. Caching only covers InstCombine use of KnownBits. This may explain limited gain or even slight degradation if KnownBits are not re-computed as often as we thought. >> >> Most of the time is s...

...apps. The size of the *.0.2.internalize.bc no-debug IR is ~ 30M. Here are my observations so far. Interestingly, caching produced a slight but measurable performance degradation of -O3 compile time. InstCombine takes about 35% of total execution time, of which ~20% originates from CGPassManager. ComputeKnownBits contributes 7.8%, but calls from InstCombine contribute only 2.6% to the total execution time. Caching only covers InstCombine use of KnownBits. This may explain limited gain or even slight degradation if KnownBits are not re-computed as often as we thought. Most of the time is spent in instructio...

...Having the > backend insert the mask would fix this, but I agree that someone, > somewhere needs to put in the mask if we want to allow speculation > here, and the target can’t do the variable extract in a register. I'd rather the frontend do this if the language wants it. We can use ComputeKnownBits when we do the speculation check, and so if there is a mask, we'll be fine. > > Pete > > > > -Hal > > > >> > >> Anyway, just my 2c. > >> > >> > >> Cheers, > >> Pete > >> > >> > >>...

...   t17: i64 = ctlz t16         t22: i64 = add t17, Constant:i64<-32>       t20: i32 = truncate t22     t15: i32 = add t20, Constant:i32<-16>   t7: ch,glue = CopyToReg t0, Register:i32 $r2l, t15   t8: ch = SystemZISD::RET_FLAG t7, Register:i32 $r2l, t7:1 It seems that SelectionDAG::computeKnownBits() has a case for ISD::CTLZ, and it seems to figure out that the high bits of t17 are zero, as expected. t17 is guaranteed to have a value between 48 and 64, so there could not be any overflow here, even though I am not sure if that's the problem or not... Should DAGCombiner::visitADD() hand...

Hello, all. Recently we noticed a problem with function pointer alignment in LLVM: the value tracking analysis (specifically the 'computeKnownBits' function) uses function alignment to infer that the least significant bits of function pointers are known to be zero. Unfortunately, this is not correct for ARM targets: the least significant bit of a function pointer stores the ARM/Thumb state information (i.e., the LSB is set for Thumb f...

...s user 0m0.296s user 0m0.299s user 0m0.296s With your patch applied: user 0m0.264s user 0m0.269s user 0m0.269s user 0m0.268s user 0m0.268s So the time for all of -O2 has dropped to 89.6% of the baseline (improvement of 11.5%). A profile shows time spent in InstCombine->computeKnownBits dropped from 58 ms to 15 ms (lines up with the overall time drop), so we're about 4x faster in ValueTracking with the caching. On Wed, Mar 22, 2017 at 7:36 AM, Hal Finkel via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > On 03/20/2017 11:51 PM, Gerolf Hoflehner wrote: > &gt...

...t that much harder to understand what is and is not canonical at a given point during the execution of the optimizer. If a canonicalization is too costly to achieve, maybe it is not a reasonable one? It is also not clear to me that canonicalizations that are using complex analyses (ValueTracking / computeKnownBits) are really making it easy to "understand what is canonical” anyway. This is my impression in general as the scope of what is needed to achieve the transformation gets larger: the more context needed the less it looks like a “canonicalization” to me. WDYT? — Mehdi > > I'd be muc...

...es under ExpensiveCombines is that it will make it that much harder to understand what is and is not canonical at a given point during the execution of the optimizer. > > I'd be much more interested in a patch which caches the result of frequently called ValueTracking functionality like ComputeKnownBits, ComputeSignBit, etc. which often doesn't change but is not intelligently reused. I imagine that the performance win might be quite comparable. Can you back this up with measurements? Caching schemes are tricky. Is there a way to evaluate when the results of ComputeKnownBits etc is actually ef...