[LLVMdev] Floating-point range checks

[Philip Reames]

On 01/08/2015 11:32 AM, Sanjay Patel wrote:
> http://llvm.org/bugs/show_bug.cgi?id=17713 shows another case where 
> some kind of FP value tracking would be useful.
>
> gcc can transform this division into multiplication by reciprocal:
> 	if (y == 2.0) return x/y;
Just to note, this is probably a different case than eliminating range 
checks.  I'm really surprised that GVN and/or JumpThreading (via LVI 
Constant) doesn't get this though.  Propagating a constant along an edge 
is pretty much independent of any floating point semantics.

In fact, looking at LVI, this looks *really* simple to add.  See the 
first check in getEdgeValueLocal.  We're talking probably 20 LOC 
(assuming it doesn't flush out other bugs.)

I haven't glanced at the GVN case.


>
>
> On Thu, Jan 8, 2015 at 12:02 PM, Hal Finkel <hfinkel at anl.gov 
> <mailto:hfinkel at anl.gov>> wrote:
>
>     ----- Original Message -----
>     > From: "Arch Robison" <arch.robison at intel.com
>     <mailto:arch.robison at intel.com>>
>     > To: "Philip Reames" <listmail at philipreames.com
>     <mailto:listmail at philipreames.com>>, llvmdev at cs.uiuc.edu
>     <mailto:llvmdev at cs.uiuc.edu>
>     > Sent: Thursday, January 8, 2015 12:54:32 PM
>     > Subject: Re: [LLVMdev] Floating-point range checks
>     >
>     >
>     > 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 subsets of the
>     > eight-element set:
>     >
>     > {-inf,<0,-0,+0,>0,+inf,-nan,+nan},
>     >
>     > where <0 and >0 denote finite negative/positive numbers
>     respectively.
>     >
>
>     I'm not sure. Checks against 1.0 are also common. Why not just add
>     a FP range class, like our constant range, and go from there?
>
>      -Hal
>
>     >
>     >
>     > - Arch
>     >
>     >
>     >
>     >
>     >
>     > From: Philip Reames [mailto:listmail at philipreames.com
>     <mailto:listmail at philipreames.com>]
>     > Sent: Wednesday, January 7, 2015 6:03 PM
>     > To: Robison, Arch; llvmdev at cs.uiuc.edu <mailto: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 example, you're probably going to want a pattern
>     > in SimplifyFCmp of the form:
>     > matcher: sqrt_call( fadd(Value(X), SpecificValue(X)), fadd(Value(Y),
>     > SpecificValue(Y)))
>     > && CannotBeNegativeZero(X) && CannotBeNegativeZero(Y)
>     >
>     > You might also look at LazyValueInfo, but that's probably of
>     > secondary interest. It's purely in terms of constant integer ranges
>     > currently.
>     >
>     > Philip
>     >
>     >
>     >
>     >
>     >
>     > On 01/07/2015 02:13 PM, Robison, Arch wrote:
>     >
>     >
>     >
>     >
>     > 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
>     >
>     >
>     >
>     >
>     >
>     >
>     >
>     >
>     >
>     >
>     >
>     >
>     >
>     > _______________________________________________ LLVM Developers
>     > mailing list LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>
>     http://llvm.cs.uiuc.edu
>     > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>     >
>     >
>     > _______________________________________________
>     > LLVM Developers mailing list
>     > LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>
>     http://llvm.cs.uiuc.edu
>     > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>     >
>
>     --
>     Hal Finkel
>     Assistant Computational Scientist
>     Leadership Computing Facility
>     Argonne National Laboratory
>
>     _______________________________________________
>     LLVM Developers mailing list
>     LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>
>     http://llvm.cs.uiuc.edu
>     http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150108/315db1e8/attachment.html>