search for: computesignbit

...eames.com] Sent: Wednesday, January 7, 2015 6:03 PM To: Robison, Arch; llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Floating-point range checks I don't believe we have much in this area currently. Generally, something like this would existing in InstCombine and ValueTracking. Take a look at ComputeSignBit in ValueTracking.cpp. This doesn't apply (?) to floating point numbers, but we'd need something equivalent for them. It looks like there may already be a start in the form of: CannotBeNegativeZero Other places to look would be SimplifyFAdd and InstCombine::visitFAdd. For this particular...

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

...o: Robison, Arch; llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] Floating-point range checks > > > > I don't believe we have much in this area currently. > > Generally, something like this would existing in InstCombine and > ValueTracking. > > Take a look at ComputeSignBit in ValueTracking.cpp. This doesn't apply > (?) to floating point numbers, but we'd need something equivalent for > them. It looks like there may already be a start in the form of: > CannotBeNegativeZero > > Other places to look would be SimplifyFAdd and InstCombine::visitF...

...v] Floating-point range checks >>> >>> >>> >>> I don't believe we have much in this area currently. >>> >>> Generally, something like this would existing in InstCombine and >>> ValueTracking. >>> >>> Take a look at ComputeSignBit in ValueTracking.cpp. This doesn't >>> apply >>> (?) to floating point numbers, but we'd need something equivalent >>> for >>> them. It looks like there may already be a start in the form of: >>> CannotBeNegativeZero >>> >>> Oth...

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

...hat 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 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. Such a patch would have the benefit of keeping the set of available transforms constant throughout the pipeline while bringing execution time down; I wouldn't be a...

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

...Combines 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 effective meaining...

...t; > >>> > >>> > >>> I don't believe we have much in this area currently. > >>> > >>> Generally, something like this would existing in InstCombine and > >>> ValueTracking. > >>> > >>> Take a look at ComputeSignBit in ValueTracking.cpp. This doesn't > >>> apply > >>> (?) to floating point numbers, but we'd need something equivalent > >>> for them. It looks like there may already be a start in the form > >>> of: > >>> CannotBeNegativeZero &...

...e 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 &gt...

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