[PATCH] Restore the sqrt -> llvm.sqrt mapping in fast-math mode
eli.friedman at gmail.com
Thu Sep 12 15:00:16 PDT 2013
On Thu, Sep 12, 2013 at 2:44 PM, Hal Finkel <hfinkel at anl.gov> wrote:
> ----- 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?
Well, if we map llvm.sqrt to sqrt and sqrt sets errno, we really do mean
"undefined behavior"... or at least something more that "returns an
> > 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)?
I'm not sure our implementation of -fno-math-errno is safe: according to
the gcc manual, it isn't equivalent to marking the math functions with
attribute((const)). (For example, the gcc manual's definition allows
transforming a call to sqrt() into the SSE sqrt instruction, but it doesn't
allow hoisting a call to sqrt out of arbitrary loops on a machine where the
sqrt() call could set errno.)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-commits