[all-commits] [llvm/llvm-project] 750e90: [mlir][ArithToAMDGPU] Add option for saturating tr...

[Krzysztof Drewniak via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 750e90e4403df23d6b271afb90e6b4d463739965
      https://github.com/llvm/llvm-project/commit/750e90e4403df23d6b271afb90e6b4d463739965
  Author: Krzysztof Drewniak <Krzysztof.Drewniak at amd.com>
  Date:   2024-01-23 (Tue, 23 Jan 2024)

  Changed paths:
    M mlir/include/mlir/Conversion/ArithToAMDGPU/ArithToAMDGPU.h
    M mlir/include/mlir/Conversion/Passes.td
    M mlir/include/mlir/Dialect/Arith/Utils/Utils.h
    M mlir/lib/Conversion/ArithToAMDGPU/ArithToAMDGPU.cpp
    M mlir/lib/Conversion/ArithToAMDGPU/CMakeLists.txt
    M mlir/lib/Dialect/Arith/Transforms/EmulateWideInt.cpp
    M mlir/lib/Dialect/Arith/Utils/Utils.cpp
    A mlir/test/Conversion/ArithToAMDGPU/8-bit-float-saturation.mlir
    M mlir/test/Conversion/ArithToAMDGPU/8-bit-floats.mlir

  Log Message:
  -----------
  [mlir][ArithToAMDGPU] Add option for saturating truncation to fp8 (#74153)

Many machine-learning applications (and most software written at AMD)
expect the operation that truncates floats to 8-bit floats to be
saturatinng. That is, they expect `truncf 256.0 : f32 to f8E4M3FNUZ` to
yield `240.0`, not `NaN`, and similarly for negative numbers. However,
the underlying hardware instruction that can be used for this truncation
implements overflow-to-NaN semantics.

To enable handling this usecase, we add the saturate-fp8-truncf option
to ArithToAMDGPU (off by default), which causes the requisite clamping
code to be emitted. Said clamping code ensures that Inf and NaN are
passed through exactly (and thus trancate to NaN).

Per review feedback, this commit efactors
createScalarOrSplatConstant() to the Arith dialect utilities and uses
it in this code. It also fixes naming of existing patterns and
switches from vector.extractelement/insertelement to
vector.extract/insert.