[PATCH] Optimize square root squared (PR21126)

[hfinkel at anl.gov]

================
Comment at: test/Transforms/InstCombine/fmul.ll:130
@@ +129,3 @@
+declare double @llvm.sqrt.f64(double)
+attributes #0 = { "unsafe-fp-math"="true" }
+
----------------
spatel wrote:
> hfinkel wrote:
> > We don't need the "unsafe-fp-math"="true" because you're just checking the 'fast' on the fmul, right? If you don't need it, please remove it.
> Thanks, Hal! Yes - the 'fast' alone is enough to do this optimization. I'm not a fan of the instruction-level fast-math flags...because it leads to another question. What should happen in the 2nd test case if it looks like this:
> 
> define double @sqrt_squared2(double %f) #0 {
>   %sqrt = call double @llvm.sqrt.f64(double %f)
>   %mul1 = fmul fast double %sqrt, %sqrt
>   %mul2 = fmul double %mul1, %sqrt
>   ret double %mul2
> }
> 
> When the %mul1 operand is replaced in the 2nd fmul instruction, does that fmul instruction now become fast too? Is fast infectious?
I think that you should change your mind ;)

The motivation behind the fast-math flags, in addition to providing client more-precise control over what instructions might be folded, was to create a "fast math" system that could survive inlining. As a result, the answer to your last question is no, it is not infectious, it is designed so that inlined "fast math" functions can have their instructions retain that property without affecting operations from the caller (which might not be "fast math" -- a particular problem when you consider LTO).

http://reviews.llvm.org/D5584