[Mlir-commits] [mlir] [mlir][gpu] Align reduction operations with vector combining kinds (PR #73423)

Lei Zhang llvmlistbot at llvm.org
Sun Nov 26 10:29:41 PST 2023


================
@@ -503,26 +503,52 @@ static std::optional<Value> createGroupReduceOp(OpBuilder &builder,
     return std::nullopt;
   }
 
+  // TODO: The SPIR-V spec does not specify how -0.0 / +0.0 and NaN values are
----------------
antiagainst wrote:

The SPIR-V spec is just providing the syntax and base semantics for those ops. For detailed numeric precision requirements, we need to look at the target client API's spec. For Vulkan there are additional spec on ["Precision and Operation of SPIR-V Instructions"](https://registry.khronos.org/vulkan/specs/1.3-extensions/html/chap52.html#spirvenv-precision-operation):

> By default, the implementation may perform optimizations on half, single, or double-precision floating-point instructions that ignore sign of a zero, or assume that arguments and results are not NaNs or infinities. If the entry point is declared with the SignedZeroInfNanPreserve Execution Mode, then NaNs, infinities, and the sign of zero must not be ignored.

I think in general we are a bit handwavy (due to the fuzziness of ML compute) regarding this part in MLIR (as we are continuing fixing various layers about these numerics; this patch being one of them) and so in SPIR-V. I won't block this pull request due to that given this makes the situation better. But could you create an issue to track the SPIR-V side to better handle floating point numerics (specifcially we need to audit how we handle fast math, emit `SignedZeroInfNanPreserve` if requested, etc.)? We aren't doing that right now.

https://github.com/llvm/llvm-project/pull/73423


More information about the Mlir-commits mailing list