fast-math: fix a bug related to square roots of negatives

[Michael Kuperstein via llvm-commits]

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:

http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20140609/220450.html
http://lists.llvm.org/pipermail/llvm-dev/2014-September/077137.html
http://llvm.org/bugs/show_bug.cgi?id=21048

Thanks,
  Michael

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
> since
> -instsimplify runs pretty late in the pipeline.
>
> Do you think extending the LibCallSimplifier is the right approach?
>
> best,
> vedant
>
> 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
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20161106/a254e585/attachment.html>