Round functions are pushed directly to libm. This is problematic for
situations where libm is not available. This patch will decompose the
roundf function by adding 0.5 to positive number to input
(subtracting for negative) following by a truncate.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Just the one fix and we should be good.
mlir/test/Dialect/Math/expand-math.mlir | ||
---|---|---|
177 | Rather than CHECK-NEXT just use CHECK-DAG on everything except the return. That way we don't enforce strict ordering on operations when not necessary. |
mlir/test/Dialect/Math/expand-math.mlir | ||
---|---|---|
182 | This should be CHECK | |
mlir/test/mlir-cpu-runner/math-polynomial-approx.mlir | ||
690 ↗ | (On Diff #512940) | So I realized a problem. These tests are in polynomial approximation but should be in a separate CPU runner test. Specifically one that validates expand-math separately works. Before landing these two CLs, could have split out the arith lowering tests to a separate file and substitute test-math-polynomial-approximation for test-expand-math and add the equivalent arith expansion. |
mlir/test/mlir-cpu-runner/math-polynomial-approx.mlir | ||
---|---|---|
690 ↗ | (On Diff #512940) | So just to note, we will want both one for arith's expand patterns and one for math's expand patterns. |
Just one small change.
mlir/test/mlir-cpu-runner/math-polynomial-approx.mlir | ||
---|---|---|
687–731 ↗ | (On Diff #513304) | We should remove this as it is in the expand math tests now. |
Rather than CHECK-NEXT just use CHECK-DAG on everything except the return. That way we don't enforce strict ordering on operations when not necessary.