[PATCH] Restore the sqrt -> llvm.sqrt mapping in fast-math mode

[Hal Finkel]

----- Original Message -----
> 
> On Thu, Sep 12, 2013 at 2:03 PM, Hal Finkel < hfinkel at anl.gov >
> wrote:
> 
> 
> 
> 
> Hello,
> 
> Please review the attached patch which restores the libm sqrt* ->
> @llvm.sqrt* mapping, but only in fast-math mode (specifically, when
> the UnsafeFPMath or NoNaNsFPMath CodeGen options are enabled). The
> @llvm.sqrt* intrinsics have slightly different semantics from the
> libm call, specifically, they are undefined when given a non-zero
> negative number (the libm calls will always return NaN for any
> negative number).
> 
> This mapping was removed in r100613, and replaced with a TODO, but at
> that time the fast-math flags were not yet implemented. Now that we
> have these, restoring this mapping is important because it will
> enable autovectorization of sqrt calls in loops (at least in
> fast-math mode).
> 
> 
> 
> 
> This is dangerous, if LangRef is actually correct. People don't
> associate -ffast-math with "my program will crash at random". :) Of
> course, LangRef is probably overstating the issue.

I agree, and the LangRef does indeed say "undefined behavior", but I assume that should really mean, "returns an undefined value." Do you agree?

> 
> 
> That said, there's actually a general issue here: if we map the LLVM
> intrinsics to libc functions, and the libc functions set errno, we
> could break code that depends on errno for non-math calls (e.g.
> fopen().)

Perhaps, but I'm not changing that here. For one thing, if the mapping does, in effect, sqrt -> llvm.sqrt -> sqrt, and only when -fmath-errno=0. Are you worried about cases where the libm functions actually do set errno (even though we have -fmath-errno=0)?

 -Hal

> 
> -Eli

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