Introduce RoundOp in the math dialect. The operation rounds the operand to the
nearest integer value in floating-point format. RoundOp lowers to LLVM
intrinsics 'llvm.intr.round' or as a function call to libm (round or roundf).
Details
- Reviewers
ftynse - Commits
- rGa0fc94ab6189: [MLIR][Math] Add round operation
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
mlir/lib/Conversion/MathToLLVM/MathToLLVM.cpp | ||
---|---|---|
40 | Ok I will follow-up. |
mlir/include/mlir/Dialect/Math/IR/MathOps.td | ||
---|---|---|
668 | The semantics here can be improved. E.g., what's the behavior if the number is x.5? Without knowing that it's hard to properly lower this, e.g., for SPIR-V GLSL round, "The fraction 0.5 will round in a direction chosen by the implementation, presumably the direction that is fastest." |
Hi @antiagainst, thanks for the remark. The operation lowers to an llvm intrinsics (llvm.round.*) or directly to libm. The semantics for the intrinsics are the same as those for libm (https://llvm.org/docs/LangRef.html#llvm-round-intrinsic). The libm semantics reads: “ The round functions round their argument to the nearest integer value in floating-point format, rounding halfway cases away from zero, regardless of the current rounding direction. (While the "inexact" floating-point exception behavior is unspecified by the C standard, the round functions are written so that "inexact" is not raised if the result does not equal the argument, which behavior is as recommended by IEEE 754 for its related functions.) .“
I will send out a doc update on Monday.
The semantics here can be improved. E.g., what's the behavior if the number is x.5? Without knowing that it's hard to properly lower this, e.g., for SPIR-V GLSL round, "The fraction 0.5 will round in a direction chosen by the implementation, presumably the direction that is fastest."