[all-commits] [llvm/llvm-project] 4a5cb9: [AggressiveInstcombine] Conditionally fold saturat...

[David Green via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 4a5cb957a1e17aa9c2a7f33d6cd98e59956d1aa3
      https://github.com/llvm/llvm-project/commit/4a5cb957a1e17aa9c2a7f33d6cd98e59956d1aa3
  Author: David Green <david.green at arm.com>
  Date:   2022-06-10 (Fri, 10 Jun 2022)

  Changed paths:
    M llvm/lib/Transforms/AggressiveInstCombine/AggressiveInstCombine.cpp
    M llvm/test/Transforms/AggressiveInstCombine/AArch64/fptosisat.ll
    M llvm/test/Transforms/AggressiveInstCombine/ARM/fptosisat.ll

  Log Message:
  -----------
  [AggressiveInstcombine] Conditionally fold saturated fptosi to llvm.fptosi.sat

This adds a fold for aggressive instcombine that converts
smin(smax(fptosi(x))) into a llvm.fptosi.sat, providing that the
saturation constants are correct and the cost of the llvm.fptosi.sat is
lower.

Unfortunately, a llvm.fptosi.sat cannot always be converted back to a
smin/smax/fptosi. The llvm.fptosi.sat intrinsic is more defined that the
original, which produces poison if the original fptosi was out of range.
The llvm.fptosi.sat will saturate any value, so needs to be expanded to
a fptosi(fpmin(fpmax(x))), which can be worse for codegeneration
depending on the target.

So this change thais conditional on the backend reporting that the
llvm.fptosi.sat is cheaper that the original smin+smax+fptost.  This is
a change to the way that AggressiveInstrcombine has worked in the past.
Instead of just being a canonicalization pass, that canonicalization can
be dependant on the target in certain specific cases.

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