This is an alternate to D129155 that uses TTI.haveFastSqrt() to avoid a potential miscompile for programs with reads of errno. Moving the transform to AggressiveInstCombine provides access to TTI.
If a sqrt call has "nnan", that implies that the input argument is never negative because sqrt of {negative number} --> NAN.
If the argument is never negative and the call can be lowered without a libcall, then we can assume that errno accesses are unchanged after lowering, so the call can be translated to the LLVM intrinsic (which is expected to become inline code).
This affects codegen for targets like x86 that have sqrt instructions, but still have to conservatively assume that a libcall may be needed to set errno as shown in issue #52620 and issue #56383.
This patch won't solve that example - we will need to extend this to use CannotBeOrderedLessThanZero or similar, enhance that analysis for new operators, and deal with llvm.assume too.
Checking that CalledFunc->getParent() doesn't make sense; the module is never going to be null. Did you mean !CalledFunc?
Can we use the getLibFunc() overload that takes a CallBase as an argument?