[LLVMdev] Optimize away sqrt in simple cases?

Warren Hunt whunt at google.com
Thu Apr 25 15:22:52 PDT 2013


I'd like to second that it would be nice to have an option for fast-math
optimizations that don't change NaN and inf.  When I was working on
rendering systems, optimizations that subtly changed precision were fine
but we relied on inf behavior.

-Warren


On Thu, Apr 25, 2013 at 3:12 PM, Christoph Grenz <
christophg+llvm at grenz-bonn.de> wrote:

> Am Dienstag, 23. April 2013, 22:50:51 schrieben Sie:
> > [...]
> > Giving more-than-expected precision can be just as bad for the user as
> less.
> >  It tends to come up in situations where the optimization would break
> some
> > symmetry, the same way that aggressively forming FMAs can break user
> code.
> > [...]
> >
> > It boils down to the fact that giving excess precision in
> > some-places-but-not-others can lead to bad behavior.
>
> Ok, I didn't think about excess precision resulting in problems.
> Now it's clear to me that fast-math is neccessary for this optimization.
>
> BTW: Is there a way to only get fast-math optimizations that don't change
> behaviour on NaNs and Infs? I think it would be an interesting possibility
> to
> allow arithmetic tranformations but only those preserving NaN and infinity
> bahavior to catch errors/corner cases.
>
> At least the pow(sqrt(x),2)=>x optimization falls into this category as I
> wrote before.
>
> > --Owen
>
> Christoph
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130425/42fa71c2/attachment.html>


More information about the llvm-dev mailing list