Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
mlir/test/Conversion/ArithmeticToSPIRV/arithmetic-to-spirv.mlir | ||
---|---|---|
1018–1019 | maxf has a different semantic regarding Nan unfortunately so this is not correct. We would need a different version of arith.maxf to be able to do that. |
mlir/test/Conversion/ArithmeticToSPIRV/arithmetic-to-spirv.mlir | ||
---|---|---|
1018–1019 | Good catch! Yeah, for the purpose of lowering arith.maxf/minf under the current semantics, we'd need emit spv.IsNan checks for both operands. If either is true, returns NaN. For other cases just return the normal maxf/minf result. (Vulkan side this also needs to be fixed. But that's a separate story.) |
Generally LGTM, just one remaining issue about the comment.
mlir/lib/Conversion/ArithmeticToSPIRV/ArithmeticToSPIRV.cpp | ||
---|---|---|
889–890 | spv.CL.fmax/fmin defines the behavior for NaN operands. It's different from OpenGL side: "If one argument is a NaN, Fmin returns the other argument. If both arguments are NaNs, Fmin returns a NaN." |
mlir/lib/Conversion/ArithmeticToSPIRV/ArithmeticToSPIRV.cpp | ||
---|---|---|
889–890 | Hmm, but doesn't the MinMaxFOpPattern help makes the behavior if one of the argument is NaN then it will result in NaN, which is what we want to mimic pytorch/tensorflow behavior? |
spv.CL.fmax/fmin defines the behavior for NaN operands. It's different from OpenGL side: "If one argument is a NaN, Fmin returns the other argument. If both arguments are NaNs, Fmin returns a NaN."