fast-math: fix a bug related to square roots of negatives
Michael Kuperstein via llvm-commits
llvm-commits at lists.llvm.org
Sun Nov 6 23:51:21 PST 2016
This has been raised several times (xalanc failing with -ffast-math isn't
new), and I believe the last time around we've explicitly decided to keep
this as undef.
A few relevant threads:
On 6 November 2016 at 23:31, Vedant Kumar via llvm-commits <
llvm-commits at lists.llvm.org> wrote:
> The optimizer doesn't handle this right now, although it probably could
> -instsimplify runs pretty late in the pipeline.
> Do you think extending the LibCallSimplifier is the right approach?
> P.S: w.r.t the problem that motivated this patch, I think a better solution
> would be to go through the test programs and change their uses of sqrt().
> > On Nov 6, 2016, at 9:31 AM, Friedman, Eli via llvm-commits <
> llvm-commits at lists.llvm.org> wrote:
> > On 11/4/2016 11:15 AM, Octav Zlatior via llvm-commits wrote:
> >> Hi,
> >> I have noticed the following behaviour while running the SPEC benchmark
> suite (built with llvm, of course). One of the tests was failing (Xalanc)
> with a segfault (because of stack overflow) because the terminating
> condition for a recursion involved NaN.
> >> I've checked a little further and I have noticed that, with fast-math,
> the square roots of negative numbers will sometimes be replaced with
> "return undef". But only sometimes, and only the square roots (for example,
> log(x) does not manifest this behaviour).
> >> It turns out a rather common way of getting the value of NaN in code is
> to assign it the return value of sqrt(<negative number>). Because of this
> bug, any such assignments will basically result undefined values.
> >> These two patches should provide a fix for this. The first is a test to
> illustrate the situation (the negative functions will be replaced with
> return undef in the IR), while the other is a fix for this bug.
> > Your patch specifically says that "sqrt(-1)" should be lowered to NaN,
> but "float x = -1.f; sqrt(x)" should be lowered to the intrinsic, which has
> undefined behavior according to LangRef. This seems dubious; changing the
> semantics of sqrt() based on the syntactic form of the source is likely to
> cause problems. For example, writing a trivial wrapper for sqrt (like the
> one in libcxx for sqrtf) breaks your check.
> > Maybe we should just kill off this transform completely? The optimizer
> knows how to handle a regular sqrt() call anyway.
> > -Eli
> > --
> > Employee of Qualcomm Innovation Center, Inc.
> > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
> > _______________________________________________
> > llvm-commits mailing list
> > llvm-commits at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-commits