search for: computesignbits

Thanks for the pointers. Looks like LazyValueInfo has the sort of infrastructure I had in mind. LVILatticeVal could be extended to floating point. (The comment "this can be made a lot more rich in the future" is an invitation :-). I'm thinking a simple lattice would address most cases of interest for floating-point checks. The lattice points for floating-point could be all

The Julia language implements sqrt(x) with conditional branch taken if x<0. Alas this prevents vectorization of loops with sqrt. Often the argument can be proven to be non-negative. E.g., sqrt(x*x+y*y). Is there an existing LLVM pass or analysis that does floating-point range propagation to eliminate such unnecessary checks? Arch D. Robison Intel Corporation -------------- next part

> Checks against 1.0 are also common. Why not just add a FP range class, like our constant range, and go from there? That's certainly another way to go. My worry is that a more complicated lattice gets us deeper into rounding-mode issues and considerably more work for smaller gain. I like the idea of creating an FPRange class. We could start with a simple one and extend it as experience

With floating point, won't you need to model a partial order for the end points? I thought there were pairs of floating point values which are incomparable. Not sure if partial order is the right abstraction, but I'm pretty sure a total order isn't. This may make implementing the range comparisons (which are themselves partially ordered) a bit tricky... Philip (Who knows just

...the value. This (and similar problems) boil down to not knowing info about a cross-block promoted value. This sort of thing can be solved with a very simple hack by adding a few maps to SDISel. The idea is that, in ISel, each cross-block CopyToReg for a Vreg can call ComputeMaskedBits and ComputeSignBits and record the known live out bit+sign information for the vreg. Later, if someone calls ComputeMaskedBits or ComputeSignBits and it recurses up to a CopyFromReg from the vreg, the information can be provided from its definition. This elegantly and cheaply solves the problem. The reason I...

I know that this has been discussed (at least in passing) a few times on the list, but I couldn't locate a bug for it. Have any architectural plans been made for it? Are there architectural roadblocks with the current LLVM infrastructure that will complicate the process? What has demotivated the implementation of this so far (is it not that big a benefit on important targets, too

> On Mar 17, 2017, at 6:12 PM, David Majnemer <david.majnemer at gmail.com> wrote: > > Honestly, I'm not a huge fan of this change as-is. The set of transforms that were added behind ExpensiveChecks seems awfully strange and many would not lead the reader to believe that they are expensive at all (the SimplifyDemandedInstructionBits and foldICmpUsingKnownBits calls being the

On 03/17/2017 04:30 PM, Mehdi Amini via llvm-dev wrote: > >> On Mar 17, 2017, at 11:50 AM, Mikhail Zolotukhin via llvm-dev >> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> Hi, >> >> One of the most time-consuming passes in LLVM middle-end is >> InstCombine (see e.g. [1]). It is a very powerful pass capable

> On Mar 17, 2017, at 6:12 PM, David Majnemer via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Honestly, I'm not a huge fan of this change as-is. The set of transforms that were added behind ExpensiveChecks seems awfully strange and many would not lead the reader to believe that they are expensive at all (the SimplifyDemandedInstructionBits and foldICmpUsingKnownBits calls

Yes, the modeling of floating-point is trickier. The wrap-around trick used by ConstantRange seems less applicable, and there are the unordered NaNs. Though in all cases, the key abstraction is a lattice of values, so an instance of FPRange should be thought of as a point on a lattice, not an interval. The lattice needs to be complicated enough the cover the cases of interest, but not so

> To (hopefully) make it easier to answer this question, I've posted my (work-in-progress) patch which adds a known-bits cache to InstCombine. > I rebased it yesterday, so it should be fairly easy to apply: https://reviews.llvm.org/D31239 - Seeing what this does to the performance of the > benchmarks mentioned in this thread (among others) would certainly be interesting. Thanks! I

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