This commit adds a pattern that expands math.roundeven into
math.round + some ops from arith. This is needed to be able to run
math.roundeven in a vectorized manner.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
mlir/lib/Dialect/Math/Transforms/ExpandPatterns.cpp | ||
---|---|---|
424 | Couldn't we just use math::CopysignOp? | |
mlir/test/Dialect/Math/expand-math.mlir | ||
86 | You will want to CHECK-DAG most of this computation if you can. This way you can break the checks into blocks. I often find it handy with explaining the sections of IR and their high level goal. | |
mlir/test/mlir-cpu-runner/expand-math-ops.mlir | ||
1 ↗ | (On Diff #513405) | There should be a new file like this that has this now at head (was just landed yesterday). If you could merge yours and it, that would be fantastic. |
mlir/test/mlir-cpu-runner/test-expand-math-approx.mlir | ||
---|---|---|
378 | This last check here is failing on my Mac and prints a positive nan |
mlir/test/mlir-cpu-runner/test-expand-math-approx.mlir | ||
---|---|---|
378 | I don't really understand why that would happen. When the input is +-nan, the expand pattern for roundeven simplifies to an identity operation. For example, if I apply to the expand pattern to func.func @main(%val : f32) -> f32 { %result = math.roundeven %val : f32 func.return %result : f32 } and then I define %val inside the function and canonicalize, I get module { func.func @main() -> f32 { %cst = arith.constant 0xFFC00000 : f32 return %cst : f32 } } Moreover, the expand pattern explicitly copies the sign from the operand at the end before returning. Does math.copysign -nan -nan produce +nan on Mac? |
mlir/test/mlir-cpu-runner/test-expand-math-approx.mlir | ||
---|---|---|
378 | Actually, the IEEE 754-2008 standard does not require the negative sign when printing a positive or negative nan:
So I think the correct way of fixing this is to just change the CHECK to nan. |
Couldn't we just use math::CopysignOp?