search for: knownbit

...he 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 instructi...

In my testing results are not that impressive, but that's because I'm now focusing on Os. For me even complete disabling of all KnownBits-related patterns in InstCombine places the results very close to the noise level. In my original patch I also had some extra patterns moved under ExpensiveCombines - and that seems to make a difference too (without this part, or without the KnownBits part I get results below 1%, which are not repo...

...during type legalize because it should be promoted. Therefore I have wanted to keep the 'and' to make correct 1 bit value. But dag combine pass is removing the 'and' on TargetLowering::SimplifyDemandedBits function. When I look at the function, even though the LHS does not have knownbit information, the code uses it with NewMask to compare LHS with RHS. Is it intended? Could someone explain it? If I missed something, please let me know. Thanks, JinGu Kang

...oo() > %y = or i32 %x, 1 > %c = call i1 @some_condition() > br i1 %c, label %true, label %false > true: > %d = udiv i32 -1, %y > false: > %z = phi i32 [ %true, %d ], [ %false, 0 ] > > Is it safe to turn the phi into a select? (ignoring profitability) > > KnownBits can tell us that %y always has at least one bit set, so it's never zero, so the udiv can never divide by zero, so it's safe to speculate, so the transform is safe. However, if %x is poison and %c is 0, the original program has no UB, and the transformed program does. It would then execute...

...e represents geomean, colored thin lines represent individual tests. The data is normalized on the first revision in the range (which is ~Jun, 2015). *** Future work *** There are still plenty of opportunities to make LLVM faster. Here is a list of some ideas that can further help compile-time: - KnownBits Cache. InstCombine and other passes use known bits, which often happens to be pretty expensive. Hal posted a patch [2] that implements a cache for known bits, but there are still some issues to fix there. - SCEV. Some parts of SCEV still need to be improved. For instance, createAddRecFromPHI funct...

...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...

...39;s less clear to me. > All trivial LICM done. By this I mean LICM which does not require aliasing or speculation safety logic. This is Loop::makeInvariant. > All trivial branches discharged. By this I mean both CFGSimplify style elimination of constant branch conditions, but also CVP, KnownBits, and SCEV. (Today, this is often true on entry to a loop pass manager, but is not upheld as passes run.) > To be clear, the above list is aspirational. We definitely don't do all of the above today. :) > > Philip > > On 03/02/2018 04:36 PM, Vedant Kumar via llvm-dev wrote:...

...ss clear to me. * All trivial LICM done.  By this I mean LICM which does not require aliasing or speculation safety logic.  This is Loop::makeInvariant. * All trivial branches discharged.  By this I mean both CFGSimplify style elimination of constant branch conditions, but also CVP, KnownBits, and SCEV.  (Today, this is often true on entry to a loop pass manager, but is not upheld as passes run.) To be clear, the above list is aspirational.  We definitely don't do all of the above today.  :) Philip On 03/02/2018 04:36 PM, Vedant Kumar via llvm-dev wrote: > Hi, > >...

Hi Sanjay, On 19 Jul 2016, at 18:54, Sanjay Patel <spatel at rotateright.com<mailto:spatel at rotateright.com>> wrote: Hi Artur - I don't think there's any reason to limit the transform to sexts only; that's just the case that was apparent in https://llvm.org/bugs/show_bug.cgi?id=20134 , so I limited it to that pattern. It's probably worth noting that I'm

Hi, I think we should remove the LoopInstSimplify pass, as it has no test coverage and no users (afaik). If you are using the pass, or think that it should stay in tree for some other reason, please let me know. Here's the patch: https://reviews.llvm.org/D44053 <https://reviews.llvm.org/D44053> vedant -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi, Over the past few years we've been trying to kill poison somehow. There have been a few proposals, but they've all failed to pass the bar and/or to gather significant support (my own proposals included). We (David, Gil, John, Juneyoung, Sanjoy, Youngju, Yoonseung, and myself) have a new proposal to kill undef instead and replace it with poison + a new 'freeze' instruction. We

...is I mean LICM which does not >> require aliasing or speculation safety logic.  This is >> Loop::makeInvariant. >> * All trivial branches discharged.  By this I mean both CFGSimplify >> style elimination of constant branch conditions, but also CVP, >> KnownBits, and SCEV.  (Today, this is often true on entry to a >> loop pass manager, but is not upheld as passes run.) >> >> To be clear, the above list is aspirational.  We definitely don't do >> all of the above today.  :) >> >> Philip >> >> On 03/0...

2017-05-26 17:47 GMT-07:00 Zachary Turner via llvm-dev < llvm-dev at lists.llvm.org>: > Changing a header file somewhere and having to spend 10 minutes waiting > for a build leads to a lot of wasted developer time. > > The real culprit here is tablegen. Can we split support and ADT into two > - the parts that tablegen depends on and the parts that it doesn't? >

...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...

...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: > &g...

...h > CrashRecoveryContext.h > DataExtractor.h > Debug.h > Endian.h > EndianStream.h > Errc.h > Errno.h > Error.h > ErrorHandling.h > ErrorOr.h > FileOutputBuffer.h > FileSystem.h > FileUtilities.h > Format*.h > GlobPattern.h > Host.h > JamCRC.h > KnownBits.h > LineIterator.h > Locale.h > ManagedStatic.h > MathExtras.h > MD5.h > Memory.h > MemoryBuffer.h > Mutex.h > MutexGuard.h > NativeFormatting.h > Options.h > Parallel.h > Path.h > PointerLikeTypeTraits.h > PrettyStackTrace.h > Printable.h > Proce...

...ored thin lines represent individual tests. The data is normalized on the first revision in the range (which is ~Jun, 2015). > > *** Future work *** > There are still plenty of opportunities to make LLVM faster. Here is a list of some ideas that can further help compile-time: > > - KnownBits Cache. InstCombine and other passes use known bits, which often happens to be pretty expensive. Hal posted a patch [2] that implements a cache for known bits, but there are still some issues to fix there. > - SCEV. Some parts of SCEV still need to be improved. For instance, createAddRecFromPHI...

...h > CrashRecoveryContext.h > DataExtractor.h > Debug.h > Endian.h > EndianStream.h > Errc.h > Errno.h > Error.h > ErrorHandling.h > ErrorOr.h > FileOutputBuffer.h > FileSystem.h > FileUtilities.h > Format*.h > GlobPattern.h > Host.h > JamCRC.h > KnownBits.h > LineIterator.h > Locale.h > ManagedStatic.h > MathExtras.h > MD5.h > Memory.h > MemoryBuffer.h > Mutex.h > MutexGuard.h > NativeFormatting.h > Options.h > Parallel.h > Path.h > PointerLikeTypeTraits.h > PrettyStackTrace.h > Printable.h > Proce...

Hello All, I have met one may-alias case from llvm's alias analysis. The code snippet is as following: char buf[4]; void test (int idx) { char *a = &buf[3 - idx]; char *b = &buf[idx]; *a = 1; *b = 2; } I can see below output from alias set tracker for above code snippet. Alias sets for function 'test': Alias Set Tracker: 1 alias sets for 2 pointer values.  

Hi, We found that today's 17.30%/11.37% performance regressions in LNT SingleSource/Benchmarks/Shootout/sieve on LNT-AArch64-A53-O3__clang_DEV__aarch64 and LNT-Thumb2v7-A15-O3__clang_DEV__thumbv7 (http://llvm.org/perf/db_default/v4/nts/daily_report/2017/1/20?filter-machine-regex=aarch64%7Carm%7Cthumb%7Cgreen) are caused by changes [rL292492] in InstCombine: https://reviews.llvm.org/D28406