[all-commits] [llvm/llvm-project] e3205b: [AggressiveInstCombine] convert sqrt libcalls with...

[Sanjay Patel via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: e3205b87655f07d70c7e7f8a86b2d009c0432e49
      https://github.com/llvm/llvm-project/commit/e3205b87655f07d70c7e7f8a86b2d009c0432e49
  Author: Sanjay Patel <spatel at rotateright.com>
  Date:   2022-07-26 (Tue, 26 Jul 2022)

  Changed paths:
    M llvm/lib/Transforms/AggressiveInstCombine/AggressiveInstCombine.cpp
    A llvm/test/Transforms/AggressiveInstCombine/X86/sqrt.ll

  Log Message:
  -----------
  [AggressiveInstCombine] convert sqrt libcalls with "nnan" to sqrt intrinsics

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 those examples - we will need to extend this to use
CannotBeOrderedLessThanZero or similar, enhance that analysis for new
operators, and/or deal with llvm.assume too.

Differential Revision: https://reviews.llvm.org/D129167