llvm dev - Apr 2013 - [LLVMdev] Optimize away sqrt in simple cases?

Hello,

Am Dienstag, 23. April 2013, 13:26:19 schrieb Owen
Anderson:
> That's a pretty seriously unsafe floating point optimization.  It could
be
> done in fast-math mode, but I doubt we currently do it.
I just saw this thread and wonder why it's "seriously" unsafe? I
see only one
problematic corner case.

For x >= 0.0 the result cannot lose precision.
For x = NaN the result is the same. sqrt(NaN) = NaN; pow(NaN,2) = NaN
For x = +inf the result is the same. sqrt(inf) = inf; pow(inf,2) = inf
For negative numbers llvm.sqrt(x) by definition has undefined behavior and so 
returning x from llvm.pow(llvm.sqrt(x),2) is acceptable.
The same should be true for -inf.

Only the result for -0.0 changes from 0.0 to -0.0.

Is there something I overlooked?
> --Owen
Christoph
 
> On Apr 23, 2013, at 1:12 PM, Erkki Lindpere <villane at gmail.com>
wrote:
> > hi!
> > 
> > I'm using LLVM 3.2. Does it optimize away llvm.pow(llvm.sqrt(x),
2) to `x`
> > with any settings? I tried with llc -O3, but that didn't do it.
> > 
> > Would be nice to write |v|² in my language ('v' being a 2D
vector say and
> > |...| and ...² being two separate infix "operators") -- when
I could
> > compare squares of lengths as well as lengths, and know that the sqrt
is
> > optimized away.
> > 
> > Erkki
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

On Apr 23, 2013, at 3:33 PM, Christoph Grenz <christophg+llvm at
grenz-bonn.de> wrote:
> Hello,
> 
> Am Dienstag, 23. April 2013, 13:26:19 schrieb Owen Anderson:
>> That's a pretty seriously unsafe floating point optimization.  It
could be
>> done in fast-math mode, but I doubt we currently do it.
> 
> I just saw this thread and wonder why it's "seriously"
unsafe? I see only one
> problematic corner case.
> 
> For x >= 0.0 the result cannot lose precision.
This is not true.  The mathematically correct result for sqrt might not be a
representable value in floating point, so rounding may occur between the two
steps.  In that case, pow2(sqrt(x)) != x.

--Owen

> This is not true.  The mathematically correct result for sqrt might not be
a representable value in floating point, so rounding may occur between the two
steps.  In that case, pow2(sqrt(x)) != x.
>
> --Owen
I think what Christoph is saying is that x will always be at least as
accurate as pow2(sqrt(x)), so it's only unsafe in so far as one's code
is actually depending on an imprecise result.

It's not an "as-if" optimization though, so it definitely would
require "fast math" or something similar; however, it seems like it
would be on the more benign side among optimizations that apply
mathematical identities that are not necessarily identities on floats,
as far as I can tell...

-Stephen