[LLVMdev] Floating-point range checks

[Hal Finkel]

----- Original Message -----
> From: "Pete Cooper" <peter_cooper at apple.com>
> To: "Arch Robison" <arch.robison at intel.com>
> Cc: "Philip Reames" <listmail at philipreames.com>, "Hal Finkel" <hfinkel at anl.gov>, llvmdev at cs.uiuc.edu
> Sent: Tuesday, January 13, 2015 1:40:42 PM
> Subject: Re: [LLVMdev] Floating-point range checks
> 
> Hi Arch
> 
> 
> Yeah, that seems reasonable to me. LazyValueInfo seems to be more
> about what ranges of values control flow defines. Knowing that 'fmul
> float %0, %0’ is >= 0 is perfectly reasonable for SimplifyFCmpInst
> to know.

Agreed (at least with non-nans?).

I don't want your work on an FPRange class to get lost, however, because we do need something like that generally speaking.

 -Hal

> 
> 
> Thanks,
> Pete
> 
> 
> 
> 
> On Jan 13, 2015, at 11:27 AM, Robison, Arch < arch.robison at intel.com
> > wrote:
> 
> 
> 
> After writing a simple FPRange, I've hit a stumbling block. I don't
> know what LLVM code should be extended to use it. I was initially
> thinking of extending LazyValueInfo, but it appears to be used for
> passes that don’t address the case that I need for Julia. I’m now
> wondering if I’m better off extending SimplifyFCmpInst to handle the
> few cases in question instead of trying to be more general. Here’s
> an example case for Julia where a trivially true domain check should
> be removed:
> 
> %jl_value_t = type {}
> @jl_domain_exception = external global %jl_value_t*
> declare void @jl_throw_with_superfluous_argument(%jl_value_t*, i32)
> declare float @llvm.sqrt.f32(float %Val)
> 
> define float @julia_f_64805(float) {
> top:
> %1 = fmul float %0, %0
> %2 = fcmp uge float %1, 0.000000e+00
> br i1 %2, label %pass, label %fail
> 
> fail: ; preds = %top
> %3 = load %jl_value_t** @jl_domain_exception, align 8
> call void @jl_throw_with_superfluous_argument(%jl_value_t* %3, i32 2)
> unreachable
> 
> pass: ; preds = %top
> %4 = call float @llvm.sqrt.f32(float %1)
> ret float %4
> }
> 
> I just want to fold the branch. Following Philip’s earlier
> suggestion, adding a routine CannotBeOrderedLessThanZero (that’s
> analogous to CannotBeNegativeZero) and making SimplifyFCmpInst use
> it would be enough to cover the cases of primary interest. Comments?
> 
> - Arch
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory